4 ms·

>XML is not a good serialization format I have never seen a good justification for this attestation that isn't some variation of "you're not accommodating the

>XML is not a good serialization format I have never seen a good justification for this attestation that isn't some variation of "you're not accommodating the optimization I want to do that is orthogonal to rendering this binary representation into a persistent representation suitable for long term storage or transmission to another system". Even the great XML/JSON flamewar ended up with the same exact ecosystem of tools being implemented for both encoding schemes. XPATH/jq JSON schema, XML Schemas, etc... It's all encoding. There isn't good or bad; there's different, and works with what I've got with no additional work. That's it.

jcranmer 5y ago
One of the particular issues I recall hearing someone talk about with XMPP is that it uses XML in a way that makes it hard to use existing libraries--I believe XMPP basically relies on an unclosed XML document that keeps getting appended to, so you need to have strong partial parsing guarantees that's unusual for XML formats.
- riedel 5y ago
  Actually removing some stuff from XPath, could give guarantees while parsing partial files. That things get ugly sometimes if XML documents aren't complete, doesn't mean that other encodings are automatically better. People should care about some good hedge grammars for extensible formats instead of getting political about that stupid encoding. There should be sth beyond current XML standards and libraries but please make it not be JSON.
- defanor 5y ago
  That's indeed a common complaint, though streaming XML parsing is not that uncommon, and there's even a common algorithm/API for that--SAX [1]--supported by multiple libraries; otherwise parsing even finite but large documents (e.g., Wikipedia dumps) would require a lot of memory. [1] https://en.wikipedia.org/wiki/Simple_API_for_XML https://en.wikipedia.org/wiki/Simple_API_for_XML
  - duskwuff 5y ago
    That really shouldn't be necessary, though! XMPP is conceptually transmitting a series of independent messages, not an arbitrarily complex document tree. There's no reason why it couldn't have recognized this at the protocol level and transmitted each message independently. (This could have been as simple as placing a CR/LF delimiter between each message and forbidding that sequence within messages.)
- gmfawcett 5y ago
  It's true that DOM parsers will have a hard time. But event-based, SAX-style parsers have no issue with an unclosed document, and there are plenty of those around (and were around, back in the heyday of XMPP).
  - olau 5y ago
    As someone who started writing an XMPP client at the time, I can confirm that the stupid unclosed document was painful. It's a leaky abstraction that goes beyond the parsers (that you can't use). It didn't help that the official documentation heralded this as a beautiful innovation.
Sebb767 5y ago
I've posted it in another subthread already, but XML, with its nesting and attributes, doesn't map particularly well to a specific programming construct. Also, you can represent an object hierarchy in a lot of ways and it's very verbose for even the smallest stuff. JSON, on the other hand, is dead simple: You have your list/array, dict/object and four value types. Representing JSON in your favorite language is straight-foward and how the serialized version of a hierarchy looks is immediately obvious in nearly all cases.

jcranmer 5y ago

One of the particular issues I recall hearing someone talk about with XMPP is that it uses XML in a way that makes it hard to use existing libraries--I believe XMPP basically relies on an unclosed XML document that keeps getting appended to, so you need to have strong partial parsing guarantees that's unusual for XML formats.

riedel 5y ago
Actually removing some stuff from XPath, could give guarantees while parsing partial files. That things get ugly sometimes if XML documents aren't complete, doesn't mean that other encodings are automatically better. People should care about some good hedge grammars for extensible formats instead of getting political about that stupid encoding. There should be sth beyond current XML standards and libraries but please make it not be JSON.
defanor 5y ago
That's indeed a common complaint, though streaming XML parsing is not that uncommon, and there's even a common algorithm/API for that--SAX [1]--supported by multiple libraries; otherwise parsing even finite but large documents (e.g., Wikipedia dumps) would require a lot of memory. [1] https://en.wikipedia.org/wiki/Simple_API_for_XML https://en.wikipedia.org/wiki/Simple_API_for_XML
- duskwuff 5y ago
  That really shouldn't be necessary, though! XMPP is conceptually transmitting a series of independent messages, not an arbitrarily complex document tree. There's no reason why it couldn't have recognized this at the protocol level and transmitted each message independently. (This could have been as simple as placing a CR/LF delimiter between each message and forbidding that sequence within messages.)
gmfawcett 5y ago
It's true that DOM parsers will have a hard time. But event-based, SAX-style parsers have no issue with an unclosed document, and there are plenty of those around (and were around, back in the heyday of XMPP).
- olau 5y ago
  As someone who started writing an XMPP client at the time, I can confirm that the stupid unclosed document was painful. It's a leaky abstraction that goes beyond the parsers (that you can't use). It didn't help that the official documentation heralded this as a beautiful innovation.

Sebb767 5y ago

I've posted it in another subthread already, but XML, with its nesting and attributes, doesn't map particularly well to a specific programming construct. Also, you can represent an object hierarchy in a lot of ways and it's very verbose for even the smallest stuff. JSON, on the other hand, is dead simple: You have your list/array, dict/object and four value types. Representing JSON in your favorite language is straight-foward and how the serialized version of a hierarchy looks is immediately obvious in nearly all cases.