Comment by w23j | Hacker News Reader

Comment by w23j | Hacker News Reader

Parent Full thread

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!)

> 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.

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).

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.

I've used jsonschema and it was fine. I didn't think it was poorly maintained. By contrast with most XML libraries I've used had a myriad of broken edge cases and security vulnerabilities brought on by its overcomplication and the maintainers' inability to keep up.

>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.

OpenAPI still functions just fine as a means of documentation and validation.

I'm allergic to all forms of code generation, to be honest. If there is an equivalent of XML in this I imagine it's even more horrendous. I can just imagine chasing down compiler errors indirectly caused by an XML switch not set shudder.

>Contrast that with for example JAXB

JAXB looks like a bolt on to work around XML's deficiencies. There's no need to marshal JSON to special funky data structures in your code because lists and hashmaps are already built in. You can just use those. An equivalent doesn't need to exist.

For schema validation, I think XML has, what, 3 ways of doing it? DTDs? XMLSchema? And now JAXB does a bit of that on the side too? Does that sound like a healthy ecosystem to you? Because it sounds like absolute dogshit to me.

> I'm allergic to all forms of code generation, to be honest. If there is an equivalent of XML in this I imagine it's even more horrendous. I can just imagine chasing down compiler errors indirectly caused by an XML switch not set shudder.

WSDL comes to mind

I see. Thanks for taking the time to reply!

Reply on news.ycombinator.com