Required vs Optional vocabularies

[handrews]

This is a follow-on from #561 (Basic vocabulary support). I would like to get this into draft-08 as well, but if it stalls, we can move forward without it. Hence the separate issue.

As proposed in #561, $vocabularies will provide a list of vocabulary URIs that an implementation can use to make a decision about whether or how to process the schema. The most basic form of this proposal would just list the URI, and the implementation has to decide what to do with unrecognized URIs.

A more useful form would allow for a meta-schema to indicate which of its constituent vocabularies MUST be understood in order to process a schema in accordance with the meta-schema. This could look something like the following (This example is contrived and not intended to be compelling. But I wanted to use vocabularies that already exist.)

{
    "$id": "http://json-schema.org/draft-08/hyper-schema",
    "$vocabularies": {
        "http://json-schema.org/draft-08/vocabularies/core-applicator": true,
        "http://json-schema.org/draft-08/vocabularies/validation-assertions": true,
        "http://json-schema.org/draft-08/vocabularies/hyper-schema": false
    }
}

or some similar syntax. In this version true means:

In order to process a schema that uses this meta-schema, you MUST understand applicators and validation. If you understand hyper-schema, then you can use that as well, but if you have no idea what this means and treat the hyper-schema keywords as unknown and ignore them, the schema author allows that.

So applicators and validation are mandatory, and hyper-schema is opportunistic. If you don't understand the first two, you're not going to be able to do anything useful. But an application may want to run a hyper-schema through an implementation optimized to support only validation and its dependencies (core applicators), and you wouldn't want it to choke on the extra keywords.

On the other hand, if you fed this to an implementation optimized to attach simple links (no validation involved) to locations in an instance, then it should reject anything with this meta-schema, because the schema author is saying that understanding validation is mandatory.

If your hyperlinks are being applied conditionally based on whether a part of the instance validates or not, then you cannot ignore validation keywords and still get the correct output.

---

More compelling use cases come when you are mixing vocabularies like an annotation vocabulary that adds code generation hints to a validation schema. Code generation really won't work with validation (at least the way I'm thinking of it right now). But you really don't want code generation to confuse regular validation, because maintaining separate schemas for those purposes is too much duplication.

[handrews]

Merged #671.