Live data from Hacker News

JSON vs. XML

corecursive.com

31–40 of 252 posts

Re: JSON vs. XML

#31
post #6

Honestly, I would relegate XML to application configuration. Trying to communicate with it with something like HTTP requests/responses is absurd.

Agreed. That and knowledge representation (ontologies) is another good use case for XML, since JSON can't natively represent attributes (has-a relationships).

I'm in a similar sphere with XML and ontological representation. I've inherited maintenance of an ontology (of sorts) that has been used in social sciences since the 1940s. Can I ask what domain you are in? How do you like to represent your ontologies? SKOS?

Re: JSON vs. XML

#32
post #30

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

I dislike SOAP and avoid working with it when I can. However, the WSDL is an excellent part of SOAP that really makes it easier to work with. Teams tended to over engineer their APIs and all kinds of cruft would develop. I like the HTTP operations with REST. I can remember hardcoding and manipulating a bunch of non-sense legacy fields just to get a ticket created via their SOAP enterprise service bus. Not to mention…

soap may have taken liberties with http to get its work done (graphql: so what??) but it really felt like we reinvented the wheel. i was consuming massive wsdls in 2013/2014 and i consume massive open api specs in 2023. did anything actually improve?

Re: JSON vs. XML

#34
post #15

For me 3 killer features of JSON are: 1. Parsing JSON doesn't require adding new firewall rules 2. There are no comments, so nobody will try to invent their own meta format or annotations in comments and instead they will put data in the JSON as they should 3. (When compared to JS) someone finally had the balls and picked one type of quotes, this makes making parser so much simpler.

> There are no comments, so nobody will try to invent their own meta format or annotations in comments and instead they will put data in the JSON as they should

It also means it's worse format for configs where you sometimes need to annotate a few nodes with comments.

Re: JSON vs. XML

#35

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

I don’t write many APIs but every JSON schema I’ve created had been automatically generated by openapi tools. Even then I’ve found schemas of very little use, because everything gets validated on deserialization anyways. Client side validation usually already taken care of in practice because users should be serializing using the same type library that deserializes or reading the docs very thoroughly.

JSON is so much more ergonomic than XML as the lingua franca because I can actually read it. That being said I still have my share of problems with JSON.

Re: JSON vs. XML

#36
post #6

Honestly, I would relegate XML to application configuration. Trying to communicate with it with something like HTTP requests/responses is absurd.

I just had to comment on the irony of this comment being embedded in a document that is delivered via HTTP and very close to valid XML.

Even if XHTML died on the wayside, HTML is imho a stereotypical example where XML is a good fit. Most of the complexity has valid use cases, and it's mostly obvious what should be an attribute and what should be content of the tag. And at least in HTML 4 you even had a doctype tag filling the role of specifying the schema used. Of course SVG is a better showcase for some other aspects of XML, with every editor putting their own metadata in, nicely partitioned into separate namespaces.

Re: JSON vs. XML

#37

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

… and have proper comments.

Re: JSON vs. XML

#38
post #26

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

JSON is great, but I surely wish it supported comments. That's the nature of its failings: too minimal.

Luckily a good number of parsers support extensions to JSON like comments and trailing comma's.

Re: JSON vs. XML

#39
post #26

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

JSON is great, but I surely wish it supported comments. That's the nature of its failings: too minimal.

That depends on what you want it to be. For a data interchange format, having no comments is arguably a strength. For a config file format, having no comments is a big weakness.

Re: JSON vs. XML

#40

Earlier quoted context omitted.

This is about JSON being created or discovered and Doug struggling to convince people it was relevant when everyone was so bought in on XML. Are you saying you think JSON shouldn't exist and everyone should use XML for everything? Tooling around XML was certainly more established, but man there was a lot of complexity built up around it.

No. JSON is great as Javascript's serialization format, but it's not as readable and robust as XML, period. I use both extensively, and for bigger objects and definitions, XML is a very clear winner. I'm a big believer in horses for courses type of approach, and my personal gripe is the push to replace one thing with another. These data types can coexist, and can be used where they shine. XML can be read and written…

What specifically about XML means it can be read/written "stupidly fast"?

It's still a text bound serialization format, you still have to parse a tree for it.

Is it just particularly mature libraries?

Post reply on HN