Understanding extended meta-schemas

[handrews]

Custom meta-schemas are problematic for interoperability, specifically when they extend standardized meta-schemas. This is because "$schema" is doing two things:

1. Indicating how the schema itself should be validated
2. Indicating the purpose and semantics of the schema (e.g. plain validation, hypermedia, or something else)

So if I have custom keywords to add to the regular validation or hyper-schema meta-schemas, which do not change their behavior in incompatible ways:

• I want to define a custom meta-schema to validate my custom extension keywords and allow my own tools to recognize that they are being used.
• I want other tools to be able to continue to recognize the underlying validation or hyper-schema vocabulary and ignore my extensions.

Note that none of this is a concern if my custom meta-schema indicates a completely different vocabulary, or adds modifications that break the expectations of the standard meta-schema(s).

We currently hide this problem- all implementations that are aware of hyper-schema at all just hard-wire that it is an extension of validation. But this kind of hard-wiring does not scale and is not generally interoperable.

This is somewhat related to #86 (extending meta-schemas), since the difficulty of extending recursion comes into play when considering solutions here. For instance, one solution to this issue would be to allow "$schema" to take an array indicating all supported vocabularies. Implementations could then ignore unrecognized vocabularies. The spec would state that schema authors MUST NOT declare contradictory semantics, or else the behavior is undefined.

Ideally, you could do this without also having to mess with the recursion problems with something like "$root" ( #86 (comment) ) although as noted in that comment, I'm not entirely sure I even like my own idea there.

[awwright]

Probably related: #151

[handrews]

Another approach would be to define some sort of "extends" or "isCompatibleWIth" link relation type. This would not impact the processing of the actual schema- the schema would still need to use "allOf" or some other mechanism to implement the extension.

But the link relation could be followed so that a user agent knows that if it does not understand the meta-schema it was given, but does understand a compatible/extension base meta-schema, that it can still make use of the schema to the extent described by the base meta-schema.

[handrews]

This issue would be solved by PR #432. [EDIT: withdrawn, and not recommended as reading material- I am socializing the ideas to find out what is and is not of interest to the community before making another go at this, but not in draft-07]

[handrews]

A problem with the link relation type approach would be that if you only have the instance and a pre-loaded set of meta-schemas or other vocabulary identifiers, then it won't work. Really, the instance needs a way to be self-contained and still communicate what vocabularies it uses without having to go out and fetch more documents from somewhere.

[handrews]

A particularly good use case for this is writing an extended meta-schema that is more strict. The standard one is intentionally very permissive, allowing a number of nonsensical combinations that would rarely be done on purpose. Numerous use cases have come up:

• additionalItems meta-schema dependency #209 forbid additionalItems unless items is an array (avoids useless keywords)
• Specify "if", "then", and "else" #375 forbid then and else unless if is present (avoids useless keywords)
• Use "additionalProperties": false to detect unexpected/misspelled keywords
• Require that type be present and match each type-specific keyword (useful for code generation or other situations in which types are fairly static)

Some of these still produce a functionally equivalent validation system (they only block keyword combinations that have no effect), while others impose real restrictions that are desirable in some cases.

[handrews]

I apparently forgot about this when I filed #558, or just wanted to reset the discussion. Either way this is a dup now so closing.