Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support custom content encodings and media types #148

Merged
merged 2 commits into from
Nov 15, 2023
Merged

Conversation

davishmcclurg
Copy link
Owner

This exposes hooks for the contentEncoding and contentMediaType
keywords, similar to the existing custom formats behavior. The provided
callables must return a tuple comprised of a validation boolean and
annotation of any type. The validation boolean is ignored in draft
2019-09 and 2020-12, because the specification says:

They do not function as validation assertions; a malformed string-encoded document MUST NOT cause the containing instance to be considered invalid.

Drafts 7 and earlier will return a validation error based on the
validation boolean. From the specification:

Implementations MAY support the "contentMediaType" and "contentEncoding" keywords as validation assertions.

All drafts forward the returned annotation as an annotation in the
overall result.

I don't love the API here, since it requires returning an array even
when it's ignored in the latest drafts, but I couldn't come up with
anything better.

Closes: #137

This exposes hooks for the `contentEncoding` and `contentMediaType`
keywords, similar to the existing custom formats behavior. The provided
callables must return a tuple comprised of a validation boolean and
annotation of any type. The validation boolean is ignored in draft
2019-09 and 2020-12, because the [specification][0] says:

> They do not function as validation assertions; a malformed string-encoded document MUST NOT cause the containing instance to be considered invalid.

Drafts 7 and earlier will return a validation error based on the
validation boolean. From the [specification][1]:

> Implementations MAY support the "contentMediaType" and "contentEncoding" keywords as validation assertions.

All drafts forward the returned annotation as an annotation in the
overall result.

I don't love the API here, since it requires returning an array even
when it's ignored in the latest drafts, but I couldn't come up with
anything better.

Closes: #137

[0]: https://json-schema.org/draft/2020-12/json-schema-validation#section-8.1
[1]: https://json-schema.org/draft-07/draft-handrews-json-schema-validation-01#rfc.section.8.2
This behavior has been around but undocumented for a while. I'm adding
this now because it's similar to custom content encodings and media
types.

Related: #137
@davishmcclurg davishmcclurg merged commit f0ee4e3 into 2.1.0 Nov 15, 2023
62 checks passed
@davishmcclurg davishmcclurg deleted the content branch November 15, 2023 19:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant