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

Format validation #35

Open
SquareByte opened this issue Aug 4, 2022 · 1 comment
Open

Format validation #35

SquareByte opened this issue Aug 4, 2022 · 1 comment

Comments

@SquareByte
Copy link

As the JSON-Schema spec states, "format" is just annotation by default. Implementations may offer to treat it as a validation keyword. This luckily is also possible in jschon via Catalog.add_format_validators.

Two things:

  1. Question: In the spec a list of "built-in" formats is defined, referencing ISO, RFC and other definitions. Any chance or plans jschon will bring its own FormatValidator implementations for all predefined formats? Or is this out of scope?

  2. Docs bug (?): In the jschon docs example for "ipv4", the Python built-in ipaddress is used as a FormatValidator. While easy, that seems incorrect. The Python built-in ipaddress.IPv4Address does not quite accept everything that is valid according to the referenced RFC. For example "127.000.000.001" will be rejected by Python. Similar could be true in the examples for "ipv6" and "hostname", but I did not look into that.

@marksparkza
Copy link
Owner

I think it would be great for jschon to implement the built-in formats, and ultimately to support the format-assertion vocabulary, which requires full validation support for all the formats described in the spec. Up until now I've chosen to leave format validation up to the user, rather than implementing an arbitrary selection of formats which may be useful to some and not to others. Format validators are time consuming to do, and potentially tricky as you've pointed out with IP addresses, and they are not a top priority in my own use cases for the library.

But my feeling is that if you and/or others are keen to contribute individual format validators then let's go ahead and start ticking them off. We'll get them all done eventually!

Regarding the format validation example, thanks for pointing out the missed case. I'm open to suggestions as to how to fix the example - although I don't have time to look into the details of those formats any time soon. I'll be happy to accept PRs for new or modified examples.

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

No branches or pull requests

2 participants