So you do you serialise and describe a ring buffer object in JSON? How do you provide a decimal type or a complex number? How do you validate this? How do you describe this object to a foreign system? How do you query the object? How do you transform the object from one type to another? How do you transform that object to a document?
You completely misunderstand XML. It's more than an adequate markup language and more than an adequate object format.
XML has few tradeoffs other than complexity. JSON has all tradeoffs but complexity.
I see, so XML has few tradeoffs other than complexity. So I'm sure given your insistent questions, XML has a native representations for:
- A ring buffer.
- A decimal type.
- A complex number.
No, it doesn't. It's all up to the contract. And there's nothing in XML that makes it more convenient to describe a complicated contract, than JSON (or any other format).
So XML made a tradeoff of complexity, and gained nothing.
Oh, and this is one issue you won't see happen with JSON:
Yes, they managed to get full blown read access to Google's servers, including "/etc/passwd" and "/etc/hosts" by passing an XML file and using a standard XML feature.
"[N]aive XML parsers that blindly interpret the DTD of the user supplied XML documents. By doing so, you risk having your parser doing a bunch of nasty things. Some issues include: local file access, SSRF and remote file includes, Denial of Service and possible remote code execution. If you want to know how to patch these issues, check out the OWASP page on how to secure XML parsers in various languages and platforms."
You might want to reevaluate your point about complexity after reading this.
JSON has only two features:
1. Simple.
2. Readable.
The first feature make it possible for your wristwatch to parse JSON with its pin-sized CPU. The second feature makes it possible for you to parse JSON with your pin-sized... Anyway, just kidding. I'm trying to say it's easy to debug.
As for how to describe circular structures and references, and meta-types, you can see what JSON serializers like Jackson do in Java. You'll find that JSON can stretch easily to accommodate such needs.
But again, the problem was never having a format with native representation of everything under the sun.
XML's problem was that its parsers were big, heavy, complicated, poorly understood (as the XXE vulnerability shows). You would never need 90% of what an XML parser supports.
We needed the simplest, dumbest possible format that makes no assumptions about what it is you want to describe in it (except: values and collections), with the simplest, dumbest possible parser (no surpises, no complexity), so that we can then port it everywhere, and build upon it as a reliable base.
And while JSON ain't perfect, it's hell of a lot closer to that ideal than XML is.
You completely misunderstand XML. It's more than an adequate markup language and more than an adequate object format.
XML has few tradeoffs other than complexity. JSON has all tradeoffs but complexity.