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.