> I remember when XML was the main data interchange format of the web. That sucked.
I wonder why - apart from the "Should this be an element or an attribute?" issues and oddities in various implementations, XML doesn't seem like the worst thing ever.
Actually, in a web development context, I'd argue that WSDL that was used with SOAP was superior to how most people worked with REST (and how some do), since it's taken OpenAPI years to catch up and codegen is still not quite as widespread, despite notable progress: https://openapi-generator.tech/
What does leave a sour taste, however, is the fact that configuration turned into XML hell (not in a web context, but for apps locally) much like we have YAML hell nowadays, as well as people being able to focus on codegen absolved them of the need to pay lots of attention towards how intuitive their data structures are.
That said, JSON also seems okay and it being simpler is a good thing. Though personally JSON5 feels like it addresses a few things that some might find missing: https://json5.org/ (despite it being a non-starter for many, due to limited popularity/support)
Namespaces. I know why they were introduced, but they still were an incredible pain to use, especially with SOAP. You want to pass a <Customer> to the update method? No, it must be <Customer xmlns="http://example.com/api/customers/v2"> that is wrapped in a <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">.
Oh, you're writing a service? You can't just XPath your way to that <Customer>, because it's a namespaced <Customer>, your XML parser will claim there's no <Customer> in the message, you have to register your namespaces "http://example.com/api/customers/v2" and "http://www.w3.org/2003/05/soap-envelope" and look for /soap:Envelope/soap:Body/c:Customer instead.
JSON is annoyingly anal about its commas, but at least it has a single global namespace and I have never encountered a situation where I wished I could disambiguate between two different "customer" objects in my JSON payload.
That's actually a good observation, and one I hadn't previously considered
The trade-off of "that simple" is now every JSON tool has to reinvent XML-RPC, XPath, XML Schema, etc. In that way, JSON may be following the path of every other JS thing: arg, this framework is too heavy, I'm going to write a lighter one! ... ok, just with this one other feature .. ok, and this one ... arg, this framework is too heavy!
It's not the worst ever (that would be YAML) but it does have an accumulation of annoying features.
* Elements and attributes (as you said).
* Text children mixed up with elements. These two are both good for writing documents by hand (i.e. HTML) but really annoying to process.
* Namespaces are frankly confusing. I understand them now but I didn't for years - why is the namespace a URL but there's nothing actually at that URL? 99% of the time you don't even need namespaces.
* The tooling around XML is pretty good but it's all very over-engineered just like XML.
* The syntax is overly complicated and verbose. Repeated tag names everywhere. Several different kinds of quoting.
* XML schema is nice but it would be good if there was at least some support for basic types in the document. The lack of bool attributes is annoying, and there's no standard way to create a map.
JSON is better by almost every metric. It is missing namespaces but I can't think of a single time I've needed that in JSON. Mixing up elements from different schemas in the same place is arguably a terrible idea anyway.
The only bad things about JSON are the lack of comments and trailing commas (which are both fixed by JSON5) and its general inefficiency.
The inefficiency can be sometimes solved by using a binary JSON style format e.g. CBOR or Protobuf. With very large documents I've found it better to use SQLite.
I wonder why - apart from the "Should this be an element or an attribute?" issues and oddities in various implementations, XML doesn't seem like the worst thing ever.
Actually, in a web development context, I'd argue that WSDL that was used with SOAP was superior to how most people worked with REST (and how some do), since it's taken OpenAPI years to catch up and codegen is still not quite as widespread, despite notable progress: https://openapi-generator.tech/
What does leave a sour taste, however, is the fact that configuration turned into XML hell (not in a web context, but for apps locally) much like we have YAML hell nowadays, as well as people being able to focus on codegen absolved them of the need to pay lots of attention towards how intuitive their data structures are.
That said, JSON also seems okay and it being simpler is a good thing. Though personally JSON5 feels like it addresses a few things that some might find missing: https://json5.org/ (despite it being a non-starter for many, due to limited popularity/support)