$ref (and kin) across schema versions

[gregsdennis]

The spec doesn't define (and also doesn't mention that the behavior is undefined) how the reference keywords (e.g. $ref) work when referencing into schemas declaring other spec versions.

Example 1

I define schema http://my.com/schema as a draft 7 schema, but I need to reference schema http://that.one.guy.com/schema for one of my properties. Happily, that guy's schema is also defined at draft 7.

One day in the not-to-distant future, that guy upgrades their schema to draft 2019-09. Now my draft 7 schema (without being altered) references a draft 2019-09 schema.

Example 2

I define schema http://my.com/schema as a draft 7 schema, but I need to reference schema http://that.one.guy.com/schema for one of my properties. Happily, that guy's schema is also defined at draft 7.

One day in the not-to-distant future, I upgrade my schema to draft 2019-09, but it still references a draft 7 schema, which I don't control.

---

How is the validator supposed to handle this?

Ideally, I'd think the validator would take each schema document separately, and (if it supports the draft declared by the document, otherwise error) it would evaluate the reference under the draft it declares. However, I can see where a validator would get this wrong and evaluate the entire reference tree based on the draft declared by the root schema.

This should be either defined or explicitly stated that it's undefined.

[awwright]

The behavior of a schema doesn't change depending on how it is loaded (except, of course, any under-specified relative URI references in the document). So a schema marked 2019-09 will always have that behavior, even if referenced from a schema using a different version.

I don't know if this is specifically called to attention, I think it should be self-evident though.

Now one thing we are missing is tests for this (iirc), so maybe there are implementations that do it differently. We don't break reverse compatibility though (not purposefully, at least), so I'm not sure there's really a way to even test for this. (In the cases where we do remove features, implementations may still support the old behavior the same way they can support custom extensions.)

[gregsdennis]

I have a PR in the test suite that tried to do this. It's old enough now that it should be closed if it's not already.

I think we have enough diversity in versions and published schemas that we should say something in the spec. Assuming something is self-evident has historically bitten us.

[Julian]

Agreed (on all the above).

…

On Mon, Oct 7, 2019 at 4:36 PM Greg Dennis ***@***.***> wrote: I have a PR in the test suite that tried to do this. It's old enough now that it should be closed if it's not already. I think we have enough diversity in versions and published schemas that we should say something in the spec. Assuming something is self-evident has historically bitten us. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#808?email_source=notifications&email_token=AACQQXRKEKZR6TYPXTIK5STQNOMTDA5CNFSM4I6IK3YKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEARW5XY#issuecomment-539193055>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACQQXQ2XNMJ6US5ADI7TL3QNOMTDANCNFSM4I6IK3YA> .

[johandorland]

Some validators already support multiple versions detect the schema version based on the $schema that is at the root of the reference document, which is the most sane thing to do and the solution @gregsdennis proposes. I'm all for describing this behaviour more explicit and thus adding it to the spec. I would make this optional as you want to avoid the scenario where in order to create a new draft 2019-09 implementation you would also have to implement all previous drafts.

[handrews]

@johandorland is correct on the right way for this to happen.

In general, § 8.1 Meta-schemas and vocabularies, makes it more clear than ever that $schema (and, if present in the referenced meta-schema, $vocabulary) should control how a schema is processed.

§ 8.1.2.1 Default vocabularies covers some specific cases of how implementations should behave.

§ 8.2.4.5 Loading a referenced schema is the most relevant section to this specific question. We could easily add a sentence or two to the effect that each loaded schema's $schema should be respected independently.

[handrews]

I would make this optional as you want to avoid the scenario where in order to create a new draft 2019-09 implementation you would also have to implement all previous drafts.

We should put this in a patch/bugfix draft (I just made a milestone for it), in which case we don't want to require any behavior.

In general, I thinking implementations at least SHOULD check $schema and if available $vocabulary, but are free to error out on unknown or known but unsupported (e.g. old drafts) values.

[Relequestual]

@handrews Attempted to resolve this. Please provide feedback =]

[Relequestual]

PR Updated.

• Awaiting new related issue for overhall of "How to load a schema".

Otherwise, LGTM!

[handrews]

@Relequestual See #849.