Closed karenetheridge closed 2 years ago
Not in scope for this issue: supporting arbitrary external vocabularies other than those defined and used by draft-2019-09.
This thread has some things to consider: https://github.com/json-schema-org/json-schema-spec/issues/936
Blocked on #33 and other renovation tasks.
see also https://github.com/json-schema-org/json-schema-spec/pull/985
this points towards a new object type that stores dialect goodies, such as the list of vocabularies that should be enabled (and also lets us special-case the format vocabulary by still calling into that keyword for annotation collection even when it is disabled in the metaspec - can do this with a custom flag set in the dialect that only the format vocabulary will understand).
remember, <vocab uri>: false
means "still process this vocabulary if you understand it, but don't fail if you don't"
the core vocabulary cannot be disabled
$vocabulary keywords in schemas that aren't metaschemas, or $ref'd parts of metaschemas (i.e. not the root) are ignored
Note that §8.1.1 (on where the $schema keyword may occur) has changed somewhat between draft-2019-09 and 2020-xx.
can add a new interface, add_metaschema(..)
, which does everything that add_schema
does (a traversal step, instantiating a document object, etc) as well as the stuff that parsing a $schema
keyword does (parsing a document as a metaschema instantiating a dialect object, etc). see §9.1.3.
we will want to have a hardcoded dialect for draft2019-09 - i.e. a thingy that instantiates automatically when we see that $schema uri, or none at all. should have a test that checks that such an instance is identical to one that arises if we parse that metaspec manually like we would parse any other metaschema.
A more coherent algorithm for doing this is described in #45.
$js->add_vocabulary($class)
-- where $class must compose the JSON::Schema::Modern::Vocabulary role. The vocabulary's $vocabulary uri is added to a registry and then can be used by other metaschemas.
Remember that { "$vocabulary": { <uri>: false } }
is not an error if the uri is not known - we still proceed without it. but if boolean true is used, and we don't know that vocabulary, then we cannot use the metaschema.
This is now done, as of release 0.521.
When preparing a schema for use, its $schema resource must be examined for
$vocabularies
. Parsing of some standard keywords may be disabled, and additionally some nonstandard vocabularies (to be covered in a subsequent issue) could be enabled.The 'core' vocabulary can never be disabled, as per the spec (citation needed). Other vocabularies are fair game.
https://json-schema.org/draft/2019-09/json-schema-core.html#rfc.section.8.1.2