metaschema does not prevent $schema from appearing in subschemas

[Julian]

From python-jsonschema/jsonschema#553 via @dsanders11:

From the spec:

The "$schema" keyword SHOULD be used in a root schema. It MUST NOT appear in subschemas.

The metaschema however does not express this constraint.

[johandorland]

For this to be done the metaschema should distinguish between the root schema and a subschema and even though I think this constraint is expressible in JSON schema any fix will probably end up rather ugly. Personally I would be ok with leaving things as they stand as the metaschema is not designed to be a 100% airtight representation of the spec. I'm curious what other people think about this though.

[Julian]

I agree with part one of that, though philosophically, I don't think it looks good for a validation spec to not be able to conveniently represent its own constraints

…

On Fri, Jun 7, 2019, 17:43 Johan Dorland ***@***.***> wrote: For this to be done the metaschema should distinguish between the root schema and a subschema and even though I think this constraint is expressible in JSON schema any fix will probably end be rather ugly. Personally I would be ok with leaving things as they stand as the metaschema is not designed to be a 100% airtight representation of the spec. I'm curious what other people think about this though. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#748?email_source=notifications&email_token=AACQQXR2IUYG3UB4LM67363PZLJABA5CNFSM4HV3AQD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHCHDQ#issuecomment-500048782>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACQQXR2RMILKYVUWF4R5R3PZLJABANCNFSM4HV3AQDQ> .

[handrews]

I'm with @johandorland , which i think is also in alignment with how @awwright has positioned the meta-schemas. I was originally in favor of something more strict, but he convinced me that a useful but non-strict approach was better.

With the new $vocabulary and $recursiveRef approaches, it's extremely easy to extend the official meta-schema to be more strict. However, it is impossible to remove constraints in an extension (although you could separately reconstruct a less strict meta-schema describing the same vocabulary).

My recommendation would be to keep the same approach we have had, and see if folks make use of the new features to make strict versions. It can go on the release notes on the web site, even, as it's a great demonstration of those features and why we added them.

[Relequestual]

Generally, I would agree that the meta-schema should be light, but in this case, I think it's valid to be more strict here. The spec says you cannot do this. I could see a case for asking for it, but mixing draft versions is never something we wanted to address, nor should we need to.

@awwright want to weigh in on this given the above comments?

[awwright]

@handrews has it right. I might say, more specifically, there's allowed to be a difference between what authors must write, and what validators must accept. The meta-schema only needs to reject the stuff that validators must reject. What authors must write can be slightly different for things like forwards or backwards compatibility, or because behavior is undefined between implementations and it doesn't make sense to standardize that behavior.

In this case, the reason is that what constitutes a "root schema" is actually a bit subjective. Any schema is supposed to be handled the same as any other schema. When those schemas are being authored as documents, there's some additional guidelines to follow because changing the $schema inside a document isn't well thought out; the behavior is currently undefined.

[Julian]

Circling back here, I'm personally still not very clear if the answer here is that the meta schema shouldn't contain this for anything other than practical reasons (and even those sound fishy to me).

What does

the metaschema is not designed to be a 100% airtight representation of the spec

mean? And if it's true, what then is the algorithm that validators can or should use to decide whether a schema complies with the spec?

I also don't really follow

it is impossible to remove constraints in an extension (although you could separately reconstruct a less strict meta-schema describing the same vocabulary).

The language in the spec is "MUST NOT". What compliant extension could remove that?

[Relequestual]

I agree with @Julian here, and I'm not convinced by @awwright 's comments.

In this case, the reason is that what constitutes a "root schema" is actually a bit subjective.

Is it?
Draft-7 defines it.

The root schema is the schema that comprises the entire JSON document in question.

You say...

When those schemas are being authored as documents, there's some additional guidelines to follow because changing the $schema inside a document isn't well thought out; the behavior is currently undefined.

but the spec says...

The "$schema" keyword SHOULD be used in a root schema. It MUST NOT appear in subschemas.

Following logic, if you define $schema in a subschema, it is no longer a valid JSON Schema, according to the spec, as understood when applying RFC2119 Conventions and Terminology.

---

I agree it may be not be straight forward to express the constraint, and so we can assign a low priority, but the question here is, is it correct for the meta-schema to be modified to make validation closer to what the specification says? I can't think of a reason why not.

---

In terms of...

the metaschema is not designed to be a 100% airtight representation of the spec

It's defined as an informative as opposed to normative resource because we accept that some things are hard or impossible to express, and the meta-schema is sometimes more permissive than the spec because reasons. I'm not convinced there's a reason here, but I am willing to be convinced.

[handrews]

OK the issue here is related to $ref and transclusion/bundling, which is an unresolved topic so we should not do anything with the meta-schema that makes it harder to resolve.

And for that matter, I think the MUST NOT appear in subschemas might not be correct. We put the implementation behavior is subject to be revised or liberalized in future drafts CREF comment in on this topic because we weren't sure about it.

When bundling, you can end up with $schema in a subschema and it is fine as long as it is the same value of $schema as in the root schema of the overall schema document. I don't want to discuss whether this is a valid thing to do here as I know many people disagree, I am just noting that there is an unresolved issue that is part of why the meta-schema does not try to enforce this.

I am opposed to enforcing it in the meta-schema at this time.