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

Custom keyword validation #90

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

JPOverclock
Copy link

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

{
  "properties": {
    "startDate": {
      "format": "date",
      "type": "string",
      "x-min-date": "2020-01-01"
    }
  }

@JPOverclock JPOverclock force-pushed the feat/custom-keyword-validator branch from dd6bded to 520fd97 Compare August 22, 2024 20:20
@jonasschmidt
Copy link
Owner

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.

Copy link
Owner

@jonasschmidt jonasschmidt left a 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}}

@JPOverclock
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants