[draft-06 core] important - changes semantics of $schema #244
Comments
|
Different validation process is not a trivial issue. It makes meta-schema a thing of its own, essentially not a "schema" but something different. And if "meta-schema" is not a "schema", then instead of being called "meta-schema" (= "schema for schema") it should be called "schema definition file" - a different vocabulary altogether... |
|
Since the presence or absence is a RECOMMENDED, but the location is a MUST, I agree with @epoberezkin that this is a change from Draft 04 that, AFAIK, was not discussed during Draft 05 so is reasonable to discuss now. I have implemented $schema as it is now (allowed anywhere). It does add some complexity and annoyance, but orders of magnitude less than $id. I only know of two plausible use cases for non-root $schemas:
As someone working primarily with hyperschema, I don't personally need that level of control- if I don't want hyperschema in part of a schema file, I just won't use its fields. I have no specific need to mix versions either. If someone does I would like to hear from them before we put a lot of effort into supporting it. I also have concerns about how we are using $schema to indicate feature sets, which we also encourage people to extend. That is not directly relevant to this issue, but it means that for future drafts, we need to discuss the role of $schema a bit more. So I would support resetting $schema back to its Draft 04 usage for Draft 06, and taking a more thorough look at it later when we are not so close to publishing a much-awaited new version. |
|
It's difficult to understand why this change was made without knowing the use case for agruing the change. Hopefully whoever changed it can explain the use case for the chaneg... looks at @awwright |
|
I can see where you're coming from. I didn't take "This keyword MUST be located at the root of a JSON Schema" to mean that the keyword is also prohibited everywhere else. I.e. it doesn't say "must only". Also consider that subschemas can always be interpreted as a root schema (after inheriting the URI base and such), so we can't really say a property "must" exist in one but not the other. Also, though I don't think it is tested in the suite so I can't really speak to how widespread this is, it doesn't seem like most implementations even care. |
|
@awwright given that "root schema" is defined with respect to a document, a given schema will not spontaneously change from a subschema to a root schema. A human would have to do that, in which case they could deal with any necessary changes to or addition of "$schema". As long as implementations recognize documents as described in the spec, we could say that something MUST only be in a root schema. In one approach, implementations would need to keep track of documents as they are provided as input. In the other, implementations need to check "$schema" and potentially modify behavior at every level. I don't see much difference between supporting documents using a mixture of meta-schemas and supporting a mixture of subschemas within one document. I expect that a draft 06 document could reference a draft 04 document and expect it to work. I realize I'm arguing different sides of this issue in this comment vs the previous one. I am honestly not sure of the best approach. I have already implemented support for changing "$schema" anywhere, so I tend not to see it as problem. But if it's a matter of debate, my default action is to leave it how it was in Draft 04 (still by far the most widely implemented) and talk it over more for Draft 07 or later. |
@awwright "MUST be located at the root of a JSON Schema" can on its own mean only two things
Can you suggest any other meaning? Given that the same paragraph also says "It is RECOMMENDED that schema authors include this keyword in their schemas" the first meaning (MUST = required) is automatically excluded, so the only possible meaning that is left is "not allowed anywhere else". I don't see any other possible interpretation if you look at the whole paragraph and not just one sentence.
@handrews the difference is fundamental here. $schema defines the meta-schema (which is also a JSON-schema) that can be used to validate the schema (being treated as a single JSON document). There is nowhere in the spec any provision that such validation should allow swapping JSON schema on the fly with another schema (which is what replacing meta-schema on the fly would be). Allowing it makes meta-schema not JSON-schema but something else, you can no longer use the standard validation process to validate schemas against meta-schemas, you need another process. It's not important how big or small the difference is - if you want to use the same term (JSON schema) you cannot say that a different process should apply. Meta-schemas syntactically are not different from JSON schema. Allowing for even a little difference in how meta-schemas are treated compared to schemas destroys a fundamental symmetry that currently exists in the spec. So referencing schemas in other files that use different meta-schemas is absolutely fine, I use it every time meta-schema is extended, as they are separate JSON documents, so they can be independently and separately validated using different meta-schemas with the standard validation process. Mixing different $schemas within the same file means a very upside down validation process, where data itself can swap one schema with another.
That's a very selfish argument I'd say :) It's one implementation vs 40+ other. Also, as I wrote, the main problem here is not the implementation complexity, but breaking the foundation of the spec.
I'd say word for word, or even replace with "This keyword MUST be located ONLY at the root of a JSON Schema" or similar for the avoidance of any doubt. Thank you |
LOL it was intended to be silly but I forgot the smiley :-P I'm afraid I still don't get it. My code does an initial pass to find $ids, resolve base uris, find $refs, etc. (we've discussed this, IIRC Ajv does something similar). I check the $schema at the same time, and (as with $id) put the inherited/resolved value for $schema and $id in every in-memory schema. At that point, I can't tell the difference between a root schema and a subschema. They are all handled independently, so I always check with schema I'm using. I really just can't comprehend why you see it as fundamentally difference. Every schema has processing rules. "$schema" declares which rules are in effect. If it's not present, it's inherited from the parent schema. But there's absolutely no difference to me between processing schemas that were roots vs subschemas. This isn't me saying that my implementation is better or more important, but that based on it I just can't comprehend why it makes any difference at all. It doesn't matter where a schema came from (which document, root or not), they're all handled identically, which includes checking which set of rules are in force. |
|
@epoberezkin I guess the short version is
To me the file / document structure is an implementation detail of delivering the schema. The only reason that "root" schemas are at all important is that guessing the processing rules would be ridiculous (hence the need for "$schema" at each root), and depending on the request-URI as the initial base URI is unreliable since things move, are mirrored, etc (hence the recommendation to have a full URI as a "$id" at the root). Those needs are just effects of having to start somewhere with the inheritable properties each document. |
The process you are describing essentially means that you are not validating the whole schema against meta-schema, you are only validating one schema object, deciding on each object level which meta-schema to use. But meta-schema is defined to recursively iterate the object you pass to the validator, so you have to do something special to prevent it from happening, to isolate some areas of the schema from validation. If $schema can be in subschemas it can be anywhere - in properties, in items, in allOf etc. So you cannot simply pass schema object as data to validation process using meta-schema as a normal schema. And that's exactly what I am arguing against - having $schemas in subschemas makes it impossible to validate schema against meta-schema as a single object, as data. That's a fundamental change in JSON-schema being symmetric. |
OK so I think I understand your perspective at this point. I just always thought that it was supposed to be that way- each schema is evaluated on its own. A parent schema's meta-schema determines how it uses the results of its child schemas (e.g. if Draft 07 were to add an "additionalPatternProperties" field, then a parent schema using Draft 07 would apply child schemas from that field, even if those child schemas were Draft 04 and had no knowledge of that keyword- likewise a parent schema of Draft 04 would just ignore "additionalPatternProperties" even if that keyword's child schemas are Draft 07). The meta-schema's recursion is applied one level at a time, not across the entire document at once.
This is the algorithm I use everywhere, so there's nothing special needed to stop anything. |
|
@epoberezkin Your explanation probably makes the most sense, but it could just be a redundancy. Stranger language exists. Unfortunately if that is the intent, it's totally backwards: "if" and "only if" mean strictly different things in formal logic, which is why we have the statement "if and only if". I'll see if I can draw up some alternative directions to move on for $schema. We should consider what to do if it's impossible for the system to completely describe itself, a fact which is true about computational systems in general. |
@handrews But that is simply not correct. During validation of schema against meta-schema the recursion is controlled by the meta-schema itself because it has The schema you validate against meta-schema is just a JSON instance, none of the keywords it has has any special meaning. The $schema at the root level simply determines which meta-schema to use (before validation starts) and from this point schema becomes just data to be validated. Your process makes validation of schema against meta-schema fundamentally different from validating data against schema and that's exactly what I am arguing against. From the formal logic perspective that makes "meta-schema" not a "schema", because recursion is not controlled by meta-schema (as happens in case of data validation) but by schema that is validated (i.e. by the data itself). |
@awwright I agree with @handrews here that it's best to keep exactly the same language in draft-06 as we have in draft-04, not to hold 06, and discuss/agree/implement any changes in the next version.
Sorry, it's over my head :) Could you please clarify what it refers to? |
@awwright Ok, I got it. It's about using JSON-schema spec to describe/validate schemas :) JSON-schema is defined for structural validation of JSON instances, rather than for full/semantic description/validation. So from this perspective JSON-schema is absolutely sufficient to describe the structure of JSON-schema. "Completely" describing JSON-schema, or any other data structure, is out of scope of JSON-schema, so it is not a problem at all that it cannot be done. "Completely" describing JSON-schema is the purpose of I-D document. That's why I always agree with you that meta-schema should define a subset of requirements (=only structural requirements) defined by I-D. But changing JSON-schema to a point where it becomes impossible to use JSON-schema to describe its own structure doesn't seem to be wise - it means making your own tool unusable for your own purposes. That's what this whole argument is about. The ultimate destination on this journey would be not to use JSON and use any other independent DSL. And there are quite a few people who advocate it by the way, but I don't think it's a good idea... If we all agree that using JSON for JSON-schema is a holy cow that we are not going to touch, then it is wise to limit the possible structures for JSON-schema in such way that JSON-schema can be used to validate the structure of JSON schemas... And that means allowing $schema only at the root. |
|
@epoberezkin Gödel's incompleteness theorem sort of concludes it's impossible for a sufficiently complex formal system to completely describe itself. Or at least that there's true statements that are impossible to prove. Specifically:
For JSON Schema, presumably, we want to restrict the grammar of schemas to that which can be validated in a finite amount of computing time. The draft-wright-json-schema-00 document was primarily supposed to address references and ambiguous and contradictory language... We can modify the requirements, but the way it was phrased in draft-zyp-json-schema-04 just isn't usable. And draft-zyp-json-schema-03 doesn't have any usage requirements at all. |
|
@epoberezkin we're in a slightly odd position right now because different meta-schemas are often different versions rather than different vocabularies. This is part of why I think $schema is a mess- it conflates versions and vocabularies, and extending a vocabulary by creating a new meta-schema obscures the original vocabulary and prevents programs that understand the base vocabulary from understanding anything at all. But I digress. Thinking of a situation where we have a final $RFC so that the core syntax (specifically $schema) is stable. $schema is for choosing the vocabulary. Because it is part of the core, $schema is a consistent part of every vocabulary. So yes, meta-schema A recurses with "#" back to itself, but the first thing that happens, in ANY vocabulary, is to check $schema to see if the vocabulary is changing. I guess I do see validating a schema against a meta-schema as a separate thing. Both are of media type schema+json and the appropriate rules come into play. $schema is only a meta-schema selector (it should be $metaSchema IMNSHO). plain json and other +json media types don't have such a capability. @awwright as I've said I'd be find to drop back to Draft 04 wording. Can we just do that and put the deep examination of $schema off until after we ship Draft 06? We need to get something workable out the door. |
I Agree. That means schema validation MUST be decidable and hopefully is a good problem regarding to complexity theory in time and space. |
@handrews I agree that this problem exists
I disagree with that. Why would you use the word $schema to define "vocabulary" and not "JSON-schema"? Why not use $vocabulary instead? And $vocabulary doesn't have to be meta-schema URI (or any URI, instead it can be some other defined string. Why can't we call things what they are rather than using a word to mean what it is not? Also this approach would preserve backward compatibility with what $schema means now.
That doesn't make any sense to me at all because of the reasons I explained above
While it's not impossible, it's an unnecessary complication. All you gain from it is a very questionable convenience at the price of fundamental shift. JSON schema is for validating JSON instances which can not switch the schema that is used for validation. It's only natural to want for meta-schema to be a JSON schema rather than a "separate thing". |
@handrews And by the way, whatever keyword we use to define vocabulary, I think it should also be defined on a file level as different vocabulary implies different meta-schema in all cases. |
@awwright Right :) By the way, I'm still not sure which side of the argument you are on :) |
|
I really have no clue what is best here.
The most I've ever used $schema for is an informative "this is how old I
am" sort of deal.
Using $schema to define a profile of JSON Schema (like Swagger/OpenAPI
does), or using it to define a custom vocabulary extension (a hypothetical
JSON Schema UI vocabulary) is so niche right now, and so under-implemented,
it's hard to say anything with confidence.
…On Feb 3, 2017 15:15, "Evgeny Poberezkin" ***@***.***> wrote:
For JSON Schema, presumably, we want to restrict the grammar of schemas to
that which can be validated in a finite amount of computing time.
@awwright <https://github.com/awwright> Right :) By the way, I'm still
not sure which side of the argument you are on :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#244 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAatDSQZFf5iME5qeCSG6eZXXIOrf48Aks5rY6b8gaJpZM4L0ik1>
.
|
@handrews At the moment there is no dependence of validation process on media-type. Media type may not be available at the time of validation as JSON schema is used not only for validating "media". The fact that it is your main use case, doesn't mean that it is the most common use case. JSON schema is used to validate files, data in NoSQL databases, internal data-structures, UI forms, etc. In none of these cases media-type is available. Same for schemas themselves - they can be in files, programmatically generated, etc. So why would you make knowing media type necessary to decide how to validate an instance? |
@awwright Right. That's the argument to keep things as they are, and have these vocabulary extension ideas as experimental in particular implementations rather than as part of the spec. Using $schema to defina meta-schema to validate against, on the opposite, seems very common. |
|
@handrews if the only motivation to allow multiple $schemas is "bundling" then this motivation is both weak and wrong. "Bundling" should be out of scope of the spec. |
|
with multiple $schema it might be possible to reuse old/existing schema and mix them with new ones to avoid rewriting? |
@agebhar1 It's already possible - you can reference one schema version from another with $ref. $schema defines meta-schema to validate schema as JSON instance. If you allow multiple $schemas such validation becomes impossible, it requires different validation algorithm. |
|
@epoberezkin got it |
I proposed exactly such a thing- splitting vocabulary and version identifying from meta-validation, and I think that's about the time you told me to stop coming up with ideas and get draft 06 out the door. So I'm a little frustrated. I tried to flag the problems with this keyword earlier and got told to wait, and now you're blowing the process up over the same keyword. Bundling is a use case that has been regularly referenced by many, many people. You do not get to unilaterally exclude it from consideration. |
@handrews To bundle multiple schemas you just make an array of schemas that, in itself, is not a schema (or it can be an object, but still not a schema). And there are already several validators that accept such bundles (both arrays and objects). That achieves the goal of bundling. We can even standardise such bundles and even register a new media type. Why the bundle of schemas has to be a JSON-schema at a price of meta-schema becoming not a JSON schema but a "separate thing"? I'm all for getting the draft 6 out of the door as long as it doesn't sneak in the changes we don't have any consensus about. I don't mean intentionally by the way :) |
|
Let's try this: @awwright Are you at all willing to use the Draft 04 language here for the publication of Draft 06? If not, what is your alternative proposal (if you have none, we'll pick someone else's). @Relequestual Same question- you seemed open to the idea of reverting to Draft 04 @epoberezkin Let's see what those answers are. There is absolutely no point in arguing anything else about $schema right now, it just delays Draft 06. So no discussion of which is better (that goes for you, too, @awwright , and I cut all such language out of this reply myself). Everyone remember: The goal is to produce a usable Draft 06 before we get too many more people showing up confused about Draft 05 (which is starting to happen). Focus, please! |
|
Note I don't want to call it draft-04, since that refers to a meta-schema, so that doesn't really help us at all since meta-schema behavior is what is in question. The language in draft-zyp-json-schema-04 is simply not usable. It's literally saying that any and every root schema MUST contain a "$schema" keyword, and also it is RECOMMENDED it be included in "schemas" (for some definition of "schemas", schema document? all schemas? root schema? sub schema?). Even if another interpretation may have been intended, there's no other technically correct way to interpret the paragraph that I can come up with. Given current implementation behavior, and the definition in draft-zyp-json-schema-03, I don't see any problem with the current wording, nor do I have any problem changing it to a more restrictive wording. In either case, and until we think more about this, I don't think we're going to see any convergence on behavior from implementations. |
|
@epoberezkin Note that @awwright has a point that the Draft 03 definition of "$schema" is less ambiguous and allows "$schema" everywhere. Let's see what @Relequestual has to say. I don't know that it will be possible to satisfy everyone on this point. |
@awwright current implementation behaviour in ALL validators apart from the one @handrews describes has only one validation process, not two. Also the spec describes only one validation behaviour. So allowing $schemas in subschemas contradicts it.
It's only ambiguous if you read those sentences in isolation, together they make sense. The equivalent language where each sentence on its own can be used would be:
That removes all contradictions and the need to have two different validation processes making meta-schema a separate thing. Instead, the bundle should be a separate thing, whether within or outside of spec (in any case not in draft-06). |
|
@epoberezkin Most implementations I've surveyed don't care about the value one way or another. Mine doesn't. So I'm inclined to think this isn't that big an issue. Again, I can see how a layman might read the paragraph to mean "The $schema keyword MUST be present if and only if it is a root schema". That's probably even what was intended. But that's not what it actually says: Absent an "and only if", it means something very different. I'm not pushing for any particular direction here though, except that the draft-zyp-json-schema-04 language isn't usable as-is. Does that make sense? It would help if we had a specific paragraph to consider. What's the exact behavior being proposed? |
@awwright that's right. Not caring about the value of $schema during validation means that schema is validated as a JSON instance, not in some special way - that's exactly what I propose.
I can see your point, although this language made sense to me - I can't read it in any other way but "present if and only if it is a root schema".
Something like: "The $schema keyword is RECOMMENDED to be used in root schema. If can only be present in root schema and not allowed in sub-schemas"
$schema keyword defines meta-schema to be used to validate the WHOLE schema as a JSON instance. That means that any $schema keywords in subschemas won't be taken into account and it's better to prohibit $schema in subschemas than just ignore. |
|
I would revise to:
I would also like to add a note:
|
@awwright Everything is subject to be revised or liberalized, no? |
|
@epoberezkin True, but some things more then others I guess. The behavior of most keywords like "enum" and such is probably never going to change. There's a similar note in other areas like hyper-schema. Or that is to say, we fully expect the behavior to change in upcoming revisions. |
|
@awwright that's true. No harm in that phrase. Thank you |
Using |
|
#248 is merged. @epoberezkin happy to close this? |
|
sure! |
Draft 4 is saying:
It means that it can’t be anywhere else (in subschemas), but it doesn’t mean it is required.
Draft 6 turns it upside down:
That means that it can be located in subschema, which means different validation process for schemas against meta-schemas from the validation process of data against schema.
I don’t understand the motivation to allow $schema in subschemas. If one needs a schema with a different meta-schema it can be put in a different file and referenced. Mixing meta-schemas in one file is as bad as mixing javascript and typescript in the same file (if it were even possible) - why would anyone want to do it?
@awwright @handrews @Relequestual
The text was updated successfully, but these errors were encountered: