[w23j]

I haven't looked at JSON Schema in detail so please correct me if I am wrong, but I had the impression that the JSON Schema specification is still largely unfinished and evolving. That means you need to know which version the tool you use supports. And when I was looking for JSON Schema validators for Java all I found were projects on GitHub, which often were abandoned and referred the user to another GitHub project which was also abandoned. There does not seem to be support from an established project or vendor.

Compare that to XML where we have a plethora of established tools (Woodstoxx, JAXB, etc.).

What I have trouble to understand, which everybody else just seems to accept as obvious, is why one would take on these problems? Is JSON Schema more powerful than XML Schema? Does the use of JSON have advantages over using XML? When we are talking about a client program calling a server API with JSON/XML, why do we care about the format of data exchanged? What advantages does JSON have in this case in contrast to XML (or for that matter a binary format like Protocol Buffers)? Isn't this the most boring part of the application, which you would want to just get out of the way and work? What are the advantages of JSON over XML that would lead me to deal with the problems of evolving specifications and unreliable tooling?

(And just to repeat, since everybody seems to have a different opinion about this than me, I must be missing something and really would like to learn what!)

[Deukhoofd]

> That means you need to know which version the tool you use supports

Honestly the same issue with versioning has been my primary issue with XML Schemas in the past. XSD 1.1 for example came out over a decade ago, but is still very badly supported in most tooling I tried out.

> When we are talking about a client program calling a server API with JSON/XML, why do we care about the format of data exchanged?

We shouldn't care much, beyond debuggability (can a developer easily see what's going on), (de)serialization speed, and bandwith use. JSON and protobuf tend to be a decent chunk smaller than XML, JSON is a bit easier to read, and Protobuf is faster to (de)serialize. This means they should generally be preferred.

In the case of a client program calling a server API I'd personally have the server do the required validation on a deserialized object, instead of doing so through a schema. This is generally easier to work on for all developers in my team, and gets around all the issues with tooling. The only real reason I use schemas is when I'm writing a file by hand, and want autocompletion and basic validations. In that case versioning and tooling issues are completely in my control.

[pydry]

All schema languages are a bit like that. You can almost always add another layer on top of the validation and screw down the validation a bit harder. The strictest validation will only be achievable using a turing complete language.

OpenAPI is probably used a bit more than json schema, but it's contextually limited to APIs (which, to be fair, is mostly what JSON is used for).

[w23j]

I probably phrased my question poorly. Why would I use a tool which is not or poorly maintained for a probably already outdated version of a specs, when I can use something else, that has been used for years by countless companies in productions? The advantages must be huge. And I don't know what they are.

OpenAPI is another example. There are threads on hacker news about generating code from OpenAPI specs. These always seem to say "oh, yes don't use tool X, use tool Y it does not have that problem, although it also doesn't support Z". The consensus seems to be to not generate code from an OpenAPI specification but to just use it as documentation, since all generators are more or less broken. Contrast that with for example JAXB (which is not an exact replacement I know), which has been battle tested for years.