7.7.1.3. Annotations and Applicators
In addition to possibly defining annotation results of their own, applicator keywords aggregate the annotations collected in their subschema(s) or referenced schema(s).
should be removed or reworked. The "aggregation" language came from earlier ideas where annotations would define semantics for combining multiple values attached to the same instance location. For example, readOnly and writeOnly would be ORed. A few draft-07 implementations actually did support this to some degree.
We later decided that JSON Schema should not attempt to do this sort of thing, and would just defer all annotation usage logic to applications.
But because of that history, I had a mindset of applicators actively propagating annotations. This contributed to the confusion around the properties->additionalProperties and similar annotation communication paths, as it made it more ambiguous as to where the decision to produce or remove annotations occurred.
This means that applicators do not play a role in managing annotations other than their own, and therefore §7.7.1.3 can be dropped entirely. There are no special interactions between annotations and applicators as classes of keywords.
This section:
should be removed or reworked. The "aggregation" language came from earlier ideas where annotations would define semantics for combining multiple values attached to the same instance location. For example,
readOnlyandwriteOnlywould be ORed. A few draft-07 implementations actually did support this to some degree.We later decided that JSON Schema should not attempt to do this sort of thing, and would just defer all annotation usage logic to applications.
But because of that history, I had a mindset of applicators actively propagating annotations. This contributed to the confusion around the
properties->additionalPropertiesand similar annotation communication paths, as it made it more ambiguous as to where the decision to produce or remove annotations occurred.Ultimately, the consensus settled on keywords being able to produce annotations for use within schema objects, and only being dropped in response to failed validation at the schema object level.
This means that applicators do not play a role in managing annotations other than their own, and therefore §7.7.1.3 can be dropped entirely. There are no special interactions between annotations and applicators as classes of keywords.