-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Data access vocabulary #243
Comments
Hi @alexjg Thank you for raising this issue! This library doesn't support Draft 2019-09 (#44) yet, so the notion of custom vocabularies wasn't yet considered from the design point of view :( Though the feature is awesome, and I'll be happy to have it here :) I believe that it could be implemented as is a keyword just inside the library, but it would be nice to have it pluggable. Also, I am not sure if it would be better to implement support for Draft 2019-09 first to have some API for adding custom vocabularies. Let me know what do you think about it :) |
Glad to hear this is of interest to you 🙂 . Are you imagining a kind of plugin system for implementing vocabularies or are you thinking more that each vocabulary would be implemented in-crate and we would just check that we have an implementation of the vocabulary when we load the schema? |
I think that there could be some built-in vocabularies (like this one) + an API to plug them. Something like (just an idea): let compiled = JSONSchema::options()
.with_vocabulary(vocabularies::Data)
.compile(&schema) In this example, pub fn with_vocabulary(&mut self, vocabulary: impl Vocabulary) -> &mut Self {
// Store it in options
} Though, I don't know how this trait might look like yet. Likely it will be more clear once there will be some experiments with the implementation. |
I'm interested in using the data access vocabulary when validating schemas. I'm planning on writing a PR for
jsonschema-rs
to implement this. Is this functionality the maintainers would be interested in merging and if so are there any particular concerns that would make an implementation a good fit for this codebase?The text was updated successfully, but these errors were encountered: