Skip to content
This repository has been archived by the owner on May 2, 2020. It is now read-only.

"format" properties not supported #50

Open
creichert opened this issue Apr 7, 2017 · 1 comment
Open

"format" properties not supported #50

creichert opened this issue Apr 7, 2017 · 1 comment
Labels

Comments

@creichert
Copy link
Contributor

Is there a specific reason format validators are not currently supported?

I think this is a very important feature to implement because it's leveraged to heavily in OpenAPI specs.

  • Is the current behavior of the API to just "skip" them? I don't get validator failures.

  • How much effort would be required to support these?

I'm hoping at some point to have support in my tool for automating json schema validation w/ data contained inside a swagger spec

@seagreen
Copy link
Owner

seagreen commented Apr 7, 2017

We should support them. I haven't added them yet because I haven't needed them for any projects, and also I didn't want to start supporting any optional features until I was pretty sure the design of the rest of the library was right.

Here are the steps to add them:

  1. Re-enable the "optional/format.json" tests from here.

  2. Add a new module with format validators, copying the String module.

  3. Create actual Validators in the Draft4 module, copying the string validator entries.

  4. Add them to the schema record type. That module is a mess unfortunately, so if you have questions shoot them my way.

  5. Add the new validators to the Draft 4 schema spec, again using the string entries for reference.

  6. (optional) The examples include a demonstration of how to write your own schema specification, say if you wanted to add some custom validators of your own. This gets tested, so when the format tests are enabled it will start breaking too. So the new format validators need to be added here as well for tests to pass.

Open questions:

  • Normally a lot of the format validators like URI are implemented with a regex. This is Haskell though so maybe we should use actual parsers for them instead?

Does that all make sense? Please feel no pressure to tackle this if you don't want to, but I'm sure someone will need format validators eventually so it will be good to have a solid plan for them.

EDIT: Added the "schema record type" bullet point.

@seagreen seagreen changed the title Support "format" properties "format" properties not supported Mar 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants