Henry Andrews
Henry Andrews
Currently, our plain name fragments are restricted to the US-ASCII subset of the relevant XML plain name fragment syntax. Now that we support IRIs should we expand this as well?...
There is currently no normative language requiring "$schema" to be respected. Particularly for supporting optional vocabularies without requiring custom code (see #1300), there needs to be a mandatory requirement to...
Because XML is/was the most likely need for cross-media-type fragment identifiers. Fixes #901
Fixes #1311.
Splitting this off from #1059 which also discussed "$id" (see PR #1291 for that part), @MikeRalphson raised the use case of a meta-schema included in a schema, but not as...
This section: > [7.7.1.3. ](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-7.7.1.3)[Annotations and Applicators](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#name-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...
Note: Other folks (@jdesrosiers ? @karenetheridge ?) came up with this a while ago and apparently I objected to it (which I 100% believe but no longer recall the reason)....
In [§8.2 Implementation Requirements](https://www.ietf.org/archive/id/draft-bhutton-json-schema-validation-01.html#section-8.2) (for the `content*` keywords), we have: > Implementations MAY offer the ability to decode, parse, and/or validate the string contents automatically. However, it MUST NOT perform...
`contentSchema` is an annotation. It is never applied as part of normal evaluation (although see #1287), and shouldn't be processed at schema load time like a subschema of an applicator...