Consider forcing end-users into explicitly selecting a format behavior once Draft 8 is out

See the discussion in #403 – it might be worthwhile (i.e. it might remove some footgunning) to force even users who do not want format to do anything to have to opt into that by passing in an empty FormatChecker.

Let’s wait here though until Draft 8 is out, since one of its focuses is to further classify things in a way that makes these things generally applicable.

[Julian]

There’s a note about this in the FAQ which I’ve updated (quite awhile ago now).

@LukeMarlin and others I agree with most of the feedback here – in newer drafts the way to be more explicit is $vocabulary, though support there is still in-progress (I do hope it’ll fully land soon, working on it alongside a few other things).

I think the feedback about Understanding JSON Schema is likely good too, do take it upstream.

For now though I don’t see much more to do here locally in the library, so going to close for now beyond getting $vocabulary fully working. Of course additional feedback is always welcome.

[LukeMarlin]

Hey, end-user here 😃

As you both rightfully said, not everyone goes deep in the spec. I read http://json-schema.org/understanding-json-schema/reference/string.html#format and nothing seemed fishy. After reading the thread, I now noticed that there is a small friendly blue note saying “that’s not required”. Honestly, I completely skipped it and went straight to what the spec offers. I was really please to see ipv4 format and tried to use it with your lib.

When I noticed that “bob” was considered OK, I went through some syntax checking, spell checking, checks on other tools (that DO implement it by default: https://www.jsonschemavalidator.net/) and was really confused. That’s when/why I ended up here, checking if someone reported the issue.

Things I would have liked:

• In the “understanding jsonschema”, this should be a Warning, not a note. If one doesn’t try a wrong value, one might have relayed on an ignored check on production (that’s not on your side)
• Maybe an info about this on your readme. It is quite small and I would have seen it without doubt (except if it’s just a small note in blue 😄)
• A warn that would hint me: “I’ve noticed your schema has format, be aware that I don’t support this”
• Being forced to be explicit about the behaviour I need.

There’s many ways one can avoid to be in this case (thorough read of docs, unit tests with failing cases), but people make mistakes. A crash is problematic, a silent validation of a wrong data is potentially catastrophic.