Move "applicability" keywords to core

[handrews]

The keywords in Section 3.1 "Applicability" of the Validation spec are not specific to Validation. Let's either move them to core or make them into their own vocabulary specificaton.

Any non-trivial vocabulary will need these applicability keywords, or a set of keywords with roughly equivalent functionality. Standardizing on this set will encourage interoperable vocabularies. If we want a truly minimal core specification, then factoring out applicability into its own document will still clarify what is recommended as the base for most vocabularies (core + applicability) while still allowing for a different approach to applicability based on a minimal core for vocabularies that really want to re-imagine this functionality.

Notably, with the applicability keywords factored out, the Hyper-Schema spec will no longer directly depend on the Validation spec. It will only need core (or core + applicability), and the general notion of assertions and annotations already described in core. This eliminates a "design smell" in the current system where hyper-schema requires implementing a specific set of assertions that are unrelated to the task of annotating a JSON document with hyperlinks.

---

In terms of the content, the first sentence of §3.1:

Validation begins by applying the root schema to the complete instance document.

can be changed to:

Schema evaluation begins by applying the root schema to the complete instance document.

The remainder of the section talks about "assertions" in general, rather than the validation vocabulary in particular.

The third paragraph currently has to awkwardly list the child applicability keywords out as they are mixed in with the array and object assertions. In the core spec or their own spec they would be grouped as a section and we could drop the list and just refer to the section. Another indication that this is a good idea: it simplifies the text.

Section 3.1.1 Keyword Independence would also be simplified, as it universally applies to all current assertions, but is not universal across applicability keywords. Right now we treat the additional* applicability keywords as exceptions to an assertion-oriented concept, which muddles things a bit.

---

Putting these keywords in core would make the minimum extensible JSON Schema implementation requirements involve:

• identifying, organizing, and linking schemas ($ref, $id, $schema, and if Move "definitions" to core (as "$defs"?) #512 is accepted definitions)
• providing an interface to evaluate assertions
• providing an interface to collect annotations
• applying subschemas to instances and combining assertion results and annotation data accordingly

Putting them in their own spec would leave the first three bullets as the minimal implementation, with the fourth being a strongly recommended baseline extension required for all json-schema.org assertion and annotation vocabularies (of which we currently have two).

[handrews]

We could re-name these keywords with the $ prefix, but that would be very disruptive. I think it's easy enough to consider these keywords their own classification to explain why they do not use the prefix. But I'm open to changing them if we think we can sell that to the community.

[handrews]

@Anthropic would doing this allow UI schema, as you currently have it designed, to be specified independent of Validation? As with Hyper-Schema, obviously they could still be used together, but I'm interested if UI schema can be defined based on core (with the general concept of assertion and annotation keywords) and applicability.

[erayd]

I don't think that the applicability keywords belong in core. If they are going to be split away from validation, then I think they should live in their own document.

[handrews]

@erayd a third approach could be to put them in the core document but as a separate vocabulary from the $ keywords that are necessary for the media type to function. This would be effectively the same as putting them in their own document in terms of implementation requirements, but also indicate that this particular vocabulary is strongly recommended and required by all other proposed standard vocabularies so far.

I'm not set on any of these three options (part of core, a separate vocabulary in the core document, or a separate vocabulary in its own document). Just mulling the options.

[erayd]

@handrews That works too :-)

[handrews]

@epoberezkin what in particular is motivating your confused/sad reaction? This shouldn't actually have any impact on Ajv, it's just helping other uses of JSON Schema be more modular and clarifying the document boundaries (as we did with Validation and Hyper-Schema in draft-07)

[handrews]

My primary motivation for this proposal is to allow for vocabularies that do not want to use validation (in the form of assertions that can fail) in any way, but still want to apply keywords via subschemas.

For instance, you could write a hyper-schema without any validation assertions. It would apply links wherever the instance has an appropriate location. But it would never fail validation. At most it would simply not be able to apply links if no locations match.

Perhaps more realistic would be data definition vocabularies, such as defining a UI without validation (@Anthropic ?).

Leaving these keywords in the validation spec means that you have to reference the validation spec even when your application will never fail validation for anything. That seems a bit odd.

Putting them either in the core spec (whether required or optional- I do agree that requiring this exact set of keywords may be too restrictive) or as a separate spec would allow building both non-validating vocabularies and would allow using a completely different set of custom assertions. So that would be a validation approach that is independent of our standard approach.

These all seem like good things, given that they can be accomplished without impact to any known implementation (at least, I'm not aware of anything that implements core and not validation- the closest I can think of is implementations of JSON Reference that also support ids for changing the base URI, which might be a good argument to make the keyword set optional to support as @erayd suggests).

[epoberezkin]

@handrews what keywords exactly we are talking about here?