6 comments

[ 3.9 ms ] story [ 19.0 ms ] thread
It's an interesting article, but I just don't care about these supposed advantages. Sure, there's XPath, but there's also JSON Path. As for using XML to transform XML…why not just use Lisp to transform S-expressions?

JSON is hardly great: rather, it's the second-worst of the popular data interchange formats today. XML is the worst.

ASN.1 isn't really popular, which is good; I'd hate to have to decide between ASN.1 and XML.

JsonPath is no standard and last time I checked there only was a quick-and-dirty JavaScript implementation.
What about Protobuf? It seems to me it is lightweight than xml and asn.1, though heavyweight than json, but it suits most of the case.

If JSON has JSONPath and JSONSchema. It looks like it is another XML, then.

> What about Protobuf?

For what they are, I quite like protobufs. I tend to prefer something with a human-readable version, but protobufs do get the job done.

Human-readability is why canonical S-expressions (e.g. (3:foo3:bar), which can be displayed as (foo bar), ("foo" #626172#), (|Zm9v|3:bar) or any permutation thereof) are still the best thing around.

Oh God someone is finally speaking some sense on this topic.
Doesn't sound very convincing. What's the significant difference between those technologies? Both JSON and XML represent trees, they both allow to validate structure, specify a location on the tree. Why JSON is "data format", and XML "language" - and what is the difference between these two concepts?

I feel a bit sorry for XML. A modern evolution of SGML, which pursued ideas of reliable data storage for decades, XML was an attempt to be user-friendly, to be easy to deal with manually. It was after all rather similar to HTML, on appearance.

However, XML is too verbose for automated processing, and too inconvenient for manual work today when there is JSON - or other more "humane" formats. So it seems it's on the way out.