Blog Post on AJV & JSON Schema

[kinlane]

I recommend publishing a post on AJV. I would welcome this post to be published either here on the JSON Schema blog, API Evangelist, or even the Postman Blog.

[handrews]

What sort of things should be covered? In particular, how should AJV's problematic default-on strict mode be discussed? Since returning to the JSON Schema project, I've definitely noticed that it's hurting the community/ecosystem as a whole that the most broadly-used JavaScript implementation is by default egregiously and confusingly non-compliant.

[jeremyfiel]

I'm def interested in understanding this further. we are using tooling with underlying ajv implementations.

what exactly makes it non-compliant? what is the impact of those restrictions? can you share some examples of representative schemas with and without strict mode?

thanks!

[handrews]

@jeremyfiel strict mode is non-compliant in more ways than can be conveniently listed. A lot of them have to do with refusing to process schemas that Evgeny decided don't "make sense." Some examples include:

• {"properies": {"fooBar": {...}}, "patternProperties": {"^foo": {...}} (this is a legal schema, and both the pattern-based and name-based schemas would apply to property "foo", but strict mode will error on this
• {"if": {...}} without at least one of then or else (while strange, this construct can be used to collect annotations if the schema matches without failing validation if it does not, but strict mode errors out on this)
• array form of items (2019-09 or earlier) or prefixItems (2020-12) without various other items keywords (another perfectly normal thing to do, but strict mode considers it an error)
• erroring on unknown keywords instead of treating them as annotations or ignoring them (note that you can get this behavior easily with a custom meta-schema without resorting to non-interoperable implementation-specific configuration)
• errors out when you don't specify type in a lot of places (despite the fact that this is very useful to do in situations where the underlying type varies but some possible valid types require additional constraints)

Those are just the first few that came to mind.

Of course it would be fine if this were an option that you had to turn on. In that case, it would be effectively a built-in linter. But strict mode is on by default, and many users aren't even aware of it.

Many of the behaviors are egregious violations of the spec and very confusing, both to those who are expecting spec-compliant behavior and those who think AJV's behavior is "correct" and then try to use other implementations. So it's not just a matter of theoretical compliance, it actively damages understanding within the ecosystem and community by treating incorrect behavior as desirable.

[handrews]

And again, nearly everything that strict mode does could be implemented with custom meta-schemas that still reference the standard vocabularies (but AJV doesn't handle this case correctly because it ignores $vocabulary, although for the standard vocabularies this doesn't matter in practice because you have to tell AJV what draft it is anyway- it won't figure it out on its own from $schema/$vocabulary).

[github-actions]

Hello! 👋

This issue has been automatically marked as stale due to inactivity 😴

It will be closed in 180 days if no further activity occurs. To keep it active, please add a comment with more details.

There can be many reasons why a specific issue has no activity. The most probable cause is a lack of time, not a lack of interest.

Let us figure out together how to push this issue forward. Connect with us through our slack channel : https://json-schema.org/slack

Thank you for your patience ❤️