3 ms·

> XML didn't work as a data interchange. JSON and YAML (and TOML etc etc) beat it handily. Why not? AFAIK it worked well. See SAP and many other products.

AtlasBarfed 5y ago
Of course it could be done. It was done... with millions of lines of extra code and complexity. I'd say the immediate thing that comes to mind is that there isn't a one-line-code that would deserialize an XML message to language-universal collections (arrays/lists/vectors, dictionaries/hashmaps/assoc. arrays). The closest was XStream in java-land, which I used heavily before JSON became widespread. Secondly, it doesn't have a natural specifier for THIS IS A LIST. You're guessing or relying on mappers/marshalling to produce such things, while JSON can naturally map from JSON to an object graph without excessive mappers, annotations, etc. Other complaints: The attribute/tag dual-duty was also problematic, confused the entire problem space.
- inshadows 5y ago
  I agree that handling XML is more complex than handling JSON, but only slightly. Unless you use Java of course, where for some reason, handling XML is always pain in the ass. The complexity of XML features (namespaces and bunch of other standards) is hidden in libraries. And some of those features might be useful, only to be re-implemented in JSON, with same amount of additional complexity in libraries. Just recently I used lxml in Python to parse RSS and it gave me collection like if I used json module. Moreover, I used XPath extensively to pick parts of the XML I was interested in. This would have been more complex with manual traversal. Of course there are Python bindings to jq, but in general the jq language isn't as widespread as XPath. Then there's the slight annoyance of accessing attributes via dedicated getter methods as they're "special" as you mention. But in all, I haven't noticed millions of lines of extra code and complexity.
  - AtlasBarfed 5y ago
    I miss xpath dearly in Json

AtlasBarfed 5y ago

Of course it could be done. It was done... with millions of lines of extra code and complexity. I'd say the immediate thing that comes to mind is that there isn't a one-line-code that would deserialize an XML message to language-universal collections (arrays/lists/vectors, dictionaries/hashmaps/assoc. arrays). The closest was XStream in java-land, which I used heavily before JSON became widespread. Secondly, it doesn't have a natural specifier for THIS IS A LIST. You're guessing or relying on mappers/marshalling to produce such things, while JSON can naturally map from JSON to an object graph without excessive mappers, annotations, etc. Other complaints: The attribute/tag dual-duty was also problematic, confused the entire problem space.

inshadows 5y ago
I agree that handling XML is more complex than handling JSON, but only slightly. Unless you use Java of course, where for some reason, handling XML is always pain in the ass. The complexity of XML features (namespaces and bunch of other standards) is hidden in libraries. And some of those features might be useful, only to be re-implemented in JSON, with same amount of additional complexity in libraries. Just recently I used lxml in Python to parse RSS and it gave me collection like if I used json module. Moreover, I used XPath extensively to pick parts of the XML I was interested in. This would have been more complex with manual traversal. Of course there are Python bindings to jq, but in general the jq language isn't as widespread as XPath. Then there's the slight annoyance of accessing attributes via dedicated getter methods as they're "special" as you mention. But in all, I haven't noticed millions of lines of extra code and complexity.
- AtlasBarfed 5y ago
  I miss xpath dearly in Json