The lost art of XML
14 points by schonfinkel
14 points by schonfinkel
Some of the issues (schemas, namespaces, self-description) are solved by JSON-LD. You don't even really need to fully understand all of the semantics side of things, it's still syntactically just JSON in the end.
I think it does make some good points about XML's awkward syntax and historically being associated with unpleasant systems - binary formats are not something I've used much, but s-expression representations make it a lot more enjoyable to work with (from Lisp at least). And the separation of the data model and encoding format is definitely something that is weak in JSON.
The reason JSON lacks comments is not that would make the parser more complex, it's that it would add confusion about what data means. They would inevitably start to be used as annotations which change the meaning of the document, and that's why JSON, being meant as a machine communication format, lacks them.
How would adding commentaries that use natural language, a more expressive language, hinder interpretability, in general? Yes, they could be used to embed Haskell too, but so what?
Anyway, here's the source of why it was done:
I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
Right, exactly as Crockford says it's not the natural-language comments that are the problem. Even in JS, comments are a mix of natural language comments and directives meant to be interpreted formally. In JSON the temptation would be to do something like /* @Date */ which is essentially a way of extending JSON syntax.
Xml lost because it was slightly more work. In the libs I remember using (and still occasionally use), you have to specufy a namespace even if the doc itself doesn't explicitly have one or just uses the default.
Not the end of the world but lazy tech wins every time.
If your doc did need multiple names paces, you were probably doing something overly complex. It was usually java/c#, soap and SOA etc. So again lazy tech wins.
Xml was complex by default. Instead of c++ style "You don't pay for what you don't use" (zero-overhead principle), you always paid. High memory consumption, garbage collection, cognitive overhead etc.
I lived in xmlspy and was a daily user of xpath (ugh) at one point.
There were some good parts of xml. Still a good document format but it's not the most performant or convenient way to pass messages on software systems.