option to decode and/or validate content for the Content vocabulary

[karenetheridge]

This cannot be enabled by default. At present we just do the default behaviour, treating the Content vocabulary keywords as annotations only. But we can decode the content and validate it.

https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.8

[karenetheridge]

PS. assertion behaviour really should be configurable with the $vocabulary boolean, just as we do with the Format vocabulary.

[karenetheridge]

Adding pluggability for support for various encoding formats would be helpful. To start we can do base 16, 32, and 64 encodings. And we know that the data must be 7-bit ascii, so even if we don't know the encoding we can check for that.

We could validate various contentMediaTypes but that's probably going to be complicated.

[karenetheridge]

application/json would have high utility in an openapi application, as sometimes string parameters are passed containing encoded json content.

[karenetheridge]

# given the data at a specific location, the path to that location (as per the original evaluation results), and the original JSM::Result object, evaluate the content\* keywords that correspond to that data location using the encodings indicated therein.
sub evaluate_content ($self, $data, $data_path, $original_result, $config_override = {}) {
# find the annotations at $data_path
# foreach schema path in these annotations:
#   decode the content
#   evaluate the schema against the data
#    assemble the errors/annotations in a new result object

}

[karenetheridge]

unpinning, as this is not needed yet (and a similar interface can be sketched out separately in a consumer e.g. OpenAPI::Modern).

All we need right away is a contentMediaType registry.

[karenetheridge]

contentMediaType added in release 0.526, along with optional (but spec-violating) direct contentSchema evaluations.

[karenetheridge]

We should change the spec to split the Content vocabulary into ContentAnnotation and ContentAssertion, just like we did with Format - and keep ContentAnnotation in the default metaschema but define ContentAssertion like we defined content* behaviour in draft7 - each keyword does its stage of the decoding and contentSchema evaluates the schema against the decoded string.