support different dialects: parse $schema resource for $vocabularies

[karenetheridge]

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

[karenetheridge]

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: json-schema-org/json-schema-spec#936

[karenetheridge]

Blocked on #33 and other renovation tasks.

[karenetheridge]

see also json-schema-org/json-schema-spec#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).

[karenetheridge]

• 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.

[karenetheridge]

A more coherent algorithm for doing this is described in #45.

[karenetheridge]

$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.

[karenetheridge]

This is now done, as of release 0.521.