Feedback on #725

[erosb]

Hello,

comments on #725 are restricted, anyway, I though it may make sense to give some feedback from an implementor's point of view about the problems raised and effort.

First, I also have the feeling that json schema specification doesn't have accurate-enough goals. Many keywords seem to be quite ad-hoc and unjustified (like "dependencies"), while other things (like proper inheritance support) is just missing. As a consequence, currently the specification doesn't have formally well-defined goals, while the informally targeted goals are:

• validation: due to the high number of features, schema authors can specify so many restrictions that no other type systems can express. From a given point it is good.
• documentation generation: sort of, not a very widespread usecase, definitely no blocking problem with implementing it
• code generation: this is just in very bad shape. While the "feature bloat" is useful for validation, it is harmful for code generation. There is just no type system (in any widespread languages) which is able to express things like "not" or "contains".

So having formally defined goals & usecases, and keeping these in mind while accepting or rejecting a specification change would be beneficial.

Complexity-wise: up to draft-8 I could survive, now the library I maintain supports 3 draft versions (4, 6, 7) and I didn't even have to make breaking API changes. That's good. The most painful point was/is understanding, using and implementing "$id" and "$ref" , this is a high-frequency topic of bugreports & help requests are related to this area. There a few other little quirks, but overall I don't think the spec needs enormous efforts to implement.

Simplifying the specification has multiple effects:

• it helps new implementations to arise. Fine.
• on the other hand, exising implementations' codebase doesn't get simpler, because they still have to support previous draft versions
• what does simplify implementations is - IMHO - reducing the changes to the specification. This might sound ridiculous, but in reality it makes sense to reduce the draft release frequency and/or limit the added fetaures to things that are challenged and proved to be necessary. This actually helps keeping the specification and implementation support in sync. Considering that most json schema implementations are open-source projects not really backed by any corporates, it makes sense for me to avoid unnecessary specification changes, to avoid overwhelming implementors.

[handrews]

@erosb 725 was only closed until an admin (other than me) could respond. I'm moving your comment over and you can comment further there.