-
-
Notifications
You must be signed in to change notification settings - Fork 311
Reunite the meta-schemas #1575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We certainly can leave it how it is and it would be fine. I think there are pros and cons either way. Leaving it how it is encourages people to implement the proposal which generates feedback. However, I think we have enough feedback to know that it needs a pretty major overhaul if not a complete replacement. So, encouraging implementation might not be productive. Another perspective to consider is that we've seen several times people be confused about the meta-schema being in multiple parts. Reuniting them could make things easier for users. Another perspective is that the united meta-schema will validate faster than the modular one. My preference would be to reunite the meta-schema, but I don't feel very strongly about it. I think the only reason to keep them separated is if we expect we're just going to split them again exactly the way they were before. That would be unnecessary churn, but I don't think that's likely. |
@json-schema-org/spec-team I'd like more opinions here. Seems we have two votes for getting the meta-schema back together. |
Is this being proposed for draft-next or for a revision of draft2020-12? I don't think we can do it for draft2020-12, given https://json-schema.org/draft/2020-12/json-schema-core#section-8.1.2-6: "The "$vocabulary" keyword SHOULD be used in the root schema of any schema document intended for use as a meta-schema. It MUST NOT appear in subschemas." |
This is for the upcoming release. I'm not changing anything published. |
For 2019-09, the meta-schema was split along the vocab boundaries, and each vocab got its own, and the top-level meta-schema simply referenced these individual ones.
With vocabs being put into the feature life cycle process as a proposal, it doesn't make sense to release the meta-schemas split this way.
Should we reunite them? I don't think that we need to, but the split doesn't really make sense outside of the vocabularies concept.
Our process says that a proposed keyword should be added to the meta-schema with a
true
value to define it for implementations. (Implementation need to "know about" it.) This would apply to$vocabulary
as well. This means that we can leave the$vocabulary
keyword in, and implementations that don't support the feature should just ignore it (because they have to "know about" proposal keywords, even if they don't support them).To be more explicit, the core vocab schema would be updated to
and the (top-level) meta-schema would remain unchanged, still containing a
$vocabulary
keyword.The text was updated successfully, but these errors were encountered: