Henry Andrews
Henry Andrews
This feature added substantial complexity and security exposure for essentially no benefit. The functionality could be trivially implemented as a library on top of a JSON Schema implementation that supports...
This reworks the language around "$vocabulary" to capture the original intent in normative language. In particular, it explicitly addresses vocabularies omitted from "$vocabulary". As noted in #1294, this is based...
The current "location" behavior was kind of a dumping ground for keywords that didn't have an immediate action associated with them, namely `$defs` and `$comment`. However, _schema_ location behavior is...
I've filed issue #1304 and #1305 regarding IRI usage and extension keywords. As discussed in #1140, we are likely to move `$dynamic*` to using non-IRI identifiers. This is an architectural...
A lot of IRI processes can be the same as for URIs. For example, with IRI-reference resolution, RFC 3987 §6.5 just says to do exactly what RFC 3986 does, so...
Fixes the "$id" side of #1059, as @jdesrosiers was the only objector to that part and eventually [dropped his alternate proposal](https://github.com/json-schema-org/json-schema-spec/issues/1059#issuecomment-761151057). Note that, syntactically, this is backwards-incompatible, but it is...
While we discuss initial base IRIs, at no point do we make it clear that it's advantageous to allow an application to supply a retrieval IRI or other IRI for...
Issue #1294 (implemented by PR #1295) includes a better explanation of optional vocabulary use cases, specifically supporting annotation-only vocabularies without needing any custom code. Currently, implementations SHOULD process optional vocabularies...