-
Notifications
You must be signed in to change notification settings - Fork 98
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
Custom keyword validation #90
base: master
Are you sure you want to change the base?
Custom keyword validation #90
Conversation
dd6bded
to
520fd97
Compare
Thank you for the contribution. I like the idea, I will have some time later this week to have a look at your implementation in detail. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so I've had a look at what the standard says about this, and I think we would have to do it a slightly different way. According to this article, custom properties should always be prefixed with x-
and should be treated as annotations:
Ad-hoc keywords necessarily cannot have any functionality tied to them. That is, they're only ever annotations; their values are just returned to the user or application without any processing by the schema.
What we could do though is extend the custom format validator so that it not only gets two arguments (the value of the format
property and the data
), but can optionally get all the sibling properties of the schema as well. So you could have a custom format like date-with-min
, and in your custom format validator you could look at the other properties of the schema to find the x-min-date
and include it in the validation logic.
To do this (and maintain backward compatibility) we would have to add some additional parameter to the custom_format_validator
option so we know what the arity of the validator is, or what arguments to pass. Something like:
custom_format_validator: {MyFormatValidator, :validate, :with_schema}}
Thank you for the quick turn-around on the review! 🙏 I like your proposal and it should be simple to implement in a backwards-compatible manner 👍 I'll open a follow-up MR and we can see how it looks. As for this approach, it's very much off-spec, inspired by jsonschema which offers what I believe to be this exact functionality. Maybe it would serve as a stopgap for the draft vocabulary support, but this would indeed be hard to deprecate (or even coexist) if proper vocabulary support is introduced here. |
Adding support for optionally validating custom keywords, which are currently ignored and should continue to be so by default.
Should users provide an extended schema (or vocabulary in the future) containing custom keywords, it should be possible to extend the library's validation capabilities to include these keywords. This is done with an extension mechanism similar to the one present for
custom_format_validator
.In practice, this opens up the possibility of introducing validations for constructs such as date range validation via an extended vocabulary. e.g.: