12 ms·

> XML is needlessly complicated For messaging purposes, it is absolutely identical to JSON in this regard. Once you have many existing implementations out in t

> XML is needlessly complicated For messaging purposes, it is absolutely identical to JSON in this regard. Once you have many existing implementations out in the wild that need to interact with each other, you'll need namespaces or their NIH analogue. And JSONs with namespaces will be just as bloated as XML. Understand this: xml is meant to be read by computers, not humans. > The criticisms linked are all valid, and there are good reasons it's being abandoned It's 2022 and there is still nothing better for federated messaging.

wusspuss 5y ago
>For messaging purposes, it is absolutely identical to JSON in this regard. There's no "JSON mindset" to produce anything comparable to this crime against bandwidth and code brevity: <stream:stream from="draugr.de" id="{ID}" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"> Being sent on every connection for no reason, thrice (!) >Once you have many existing implementations out in the wild that need to interact with each other, you'll need namespaces or their NIH analogue. And JSONs with namespaces will be just as bloated as XML. Even XMPP, with XML, could do just fine without namespaces. The only place where namespaces are the differentiating factor in practice is <query/>'s and <x/>'s. Couldn't they just be be called <mam_query/> or whatnot? Oh, and namespaces specify the version. Like for ack's they specify the version 3 every time. But it's something that has to be (and is) clarified when enabling said acks anyway.
hot_gril 5y ago
> xml is meant to be read by computers, not humans. Online sources say it's meant to be both human and machine readable. It would be less bloated if it were just for machines. Seems like a generalization of HTML, which is meant to be hand-crafted in some cases. Even if it were for machines only, it'd still need a human-friendly way to manipulate and debug with, and there isn't one. Protocol buffers have the text version for humans and the serialized binary for machines, plus the generated getters/setters for code. XML is a pain to deal with no matter how you abstract it. JSON with namespaces would just mean another key-value pair in the dict or something. But I'm not sure why that's needed anyway. > It's 2022 and there is still nothing better for federated messaging. True, but federated messaging isn't in style anymore, and honestly I hardly even used XMPP. Was working on my own protocol 2 years ago that I truly believed was the best, and had a working reference impl, but had to abandon it. Got 2 jobs already.
- Andrew_nenakhov 5y ago
  Unless your XMPP client is a human, XML in your XMPP connection is meant to be read by a computer. I work with XMPP for many years and approximately zero problems we face would be solved by switching to JSON or whatever. This "JSON is better than XML" is a modern version of old religious debates like Gnome vs KDE, Pascal vs C, Christianity vs Islam.
  - hot_gril 5y ago
    Only if you switch to JSON the way they describe in the joke XEP https://xmpp.org/extensions/xep-0295.html https://xmpp.org/extensions/xep-0295.html where they force XML into JSON form instead of properly redesigning the messages. I think most people agree that XMPP messages are hard to read during debugging, and this is somehow not a problem in any of the JSON-based protocols.
    - Andrew_nenakhov 5y ago
      No. Please, stop it. XML is not a problem. Parsing it is not a problem. Reading it is not a problem, too. None of the problems ever faced by us in the development of XMPP software would have been solved if it was switched from XML to JSON, nor made even a slightly easier to solve.
      - wusspuss 4y ago
        Literally half the OP article along with half the comments here explain how XML is a problem, how it is not equivalent to any other serialization format, etc. IMO the funniest example is stanza ids. That problem wouldn't exist even if they just used said XML in a remotely sane manner. But they really wanted to go all in on it. It's the XML mindset, the need to complicate things.
joepie91_ 5y ago
> For messaging purposes, it is absolutely identical to JSON in this regard. Once you have many existing implementations out in the wild that need to interact with each other, you'll need namespaces or their NIH analogue. And JSONs with namespaces will be just as bloated as XML. It's definitely not identical. There's one major difference, that rarely seems to get mentioned but seems to be responsible for most of the pain: JSON maps directly to language-native data structures, but XML does not. The reason for this is that XML distinguishes between child nodes and attributes, but in the basic data structures that most languages have, there's no way to represent this in a conflict-free manner without doing something like `{ attributes: { ... }, children: [ ... ] }`, which is an awkward structure to query. The result is that when you're working with XML, you almost always end up with a "data API" that's designed specifically for XML (eg. classes representing nodes with getters for attributes and children), whereas with JSON you're generally working with simple nested lists and structs. This introduces relatively much complexity in what's a "hot path" in terms of development effort - every single time you want to interact with the deserialized data (which is all the time!), you have to deal with an XML-specific data structure instead of treating it as "just another source-agnostic pile of structs/objects". The result is tightly coupled code that requires the reader to be familiar with the specific XML API/representation being used, instead of it 1:1 mapping from the serialized data to a language-native data structure. That's not good! While it is true that you are likely to implement a namespace-like mechanism in JSON as well, for open protocols, the difference is that the format itself does not specially define namespaces - which means that the 1:1 mapping always remains true, and it's the protocol developer's choice to eg. reserve a `children` property to contain child nodes, with the understanding that that property then cannot be used for other things anymore. XML deserializers cannot do this; it's entirely possible for XML to exist that looks like `<tag children="yes"><subtag/></tag>`, and therefore there is no possible 1:1 mapping that a deserializer can use that's guaranteed not to make certain data inaccessible. And since child nodes are not represented as an attribute in XML's data model, you cannot expect protocol designers to avoid a specific attribute either. Bottom line: I suspect that this seemingly small design difference has far-reaching second-order effects in how deserializers are implemented, and that that is responsible for most of the pain that people experience in working with XML.
- 5y ago
andrewshadura 5y ago
> It's 2022 and there is still nothing better for federated messaging. That is untrue. Matrix is undoubtedly much better.
- Andrew_nenakhov 5y ago
  Lol no. It is a monolithic monster that will never see any other independent server vendor. Matrix is a product with a public API, not a protocol.
  - andrewshadura 5y ago
    This is, again, untrue.
    - Andrew_nenakhov 5y ago
      As jhugo said in a sister subthread, it doesn't become true if you repeat it again and again.
- jhugo 5y ago
  No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. Matrix is basically a case study in how not to design a federated chat protocol. It's bloated, it ignores all prior art and reinvents the wheel everywhere it can, and its excessive complexity means there is unlikely to ever be a wide ecosystem of good-quality implementations (especially of servers). Just because they made a foundation and threw around the word "standard" a lot doesn't mean it deserves to be the standard for chat protocols.
  - wusspuss 5y ago
    >No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. Maybe judge not by reading protocol description but by trying and using said protocol, like, chatting with people a lot? With the latter approach you'll notice a very handy feature of Matrix - not losing messages.
easrng 5y ago
JSON with namespaces exists, it's called JSON-LD, and it's used by ActivityPub among others.

wusspuss 5y ago

>For messaging purposes, it is absolutely identical to JSON in this regard. There's no "JSON mindset" to produce anything comparable to this crime against bandwidth and code brevity: <stream:stream from="draugr.de" id="{ID}" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"> Being sent on every connection for no reason, thrice (!) >Once you have many existing implementations out in the wild that need to interact with each other, you'll need namespaces or their NIH analogue. And JSONs with namespaces will be just as bloated as XML. Even XMPP, with XML, could do just fine without namespaces. The only place where namespaces are the differentiating factor in practice is <query/>'s and <x/>'s. Couldn't they just be be called <mam_query/> or whatnot? Oh, and namespaces specify the version. Like for ack's they specify the version 3 every time. But it's something that has to be (and is) clarified when enabling said acks anyway.

hot_gril 5y ago

> xml is meant to be read by computers, not humans. Online sources say it's meant to be both human and machine readable. It would be less bloated if it were just for machines. Seems like a generalization of HTML, which is meant to be hand-crafted in some cases. Even if it were for machines only, it'd still need a human-friendly way to manipulate and debug with, and there isn't one. Protocol buffers have the text version for humans and the serialized binary for machines, plus the generated getters/setters for code. XML is a pain to deal with no matter how you abstract it. JSON with namespaces would just mean another key-value pair in the dict or something. But I'm not sure why that's needed anyway. > It's 2022 and there is still nothing better for federated messaging. True, but federated messaging isn't in style anymore, and honestly I hardly even used XMPP. Was working on my own protocol 2 years ago that I truly believed was the best, and had a working reference impl, but had to abandon it. Got 2 jobs already.

Andrew_nenakhov 5y ago
Unless your XMPP client is a human, XML in your XMPP connection is meant to be read by a computer. I work with XMPP for many years and approximately zero problems we face would be solved by switching to JSON or whatever. This "JSON is better than XML" is a modern version of old religious debates like Gnome vs KDE, Pascal vs C, Christianity vs Islam.
- hot_gril 5y ago
  Only if you switch to JSON the way they describe in the joke XEP https://xmpp.org/extensions/xep-0295.html https://xmpp.org/extensions/xep-0295.html where they force XML into JSON form instead of properly redesigning the messages. I think most people agree that XMPP messages are hard to read during debugging, and this is somehow not a problem in any of the JSON-based protocols.
  - Andrew_nenakhov 5y ago
    No. Please, stop it. XML is not a problem. Parsing it is not a problem. Reading it is not a problem, too. None of the problems ever faced by us in the development of XMPP software would have been solved if it was switched from XML to JSON, nor made even a slightly easier to solve.
    - wusspuss 4y ago
      Literally half the OP article along with half the comments here explain how XML is a problem, how it is not equivalent to any other serialization format, etc. IMO the funniest example is stanza ids. That problem wouldn't exist even if they just used said XML in a remotely sane manner. But they really wanted to go all in on it. It's the XML mindset, the need to complicate things.

joepie91_ 5y ago

> For messaging purposes, it is absolutely identical to JSON in this regard. Once you have many existing implementations out in the wild that need to interact with each other, you'll need namespaces or their NIH analogue. And JSONs with namespaces will be just as bloated as XML. It's definitely not identical. There's one major difference, that rarely seems to get mentioned but seems to be responsible for most of the pain: JSON maps directly to language-native data structures, but XML does not. The reason for this is that XML distinguishes between child nodes and attributes, but in the basic data structures that most languages have, there's no way to represent this in a conflict-free manner without doing something like `{ attributes: { ... }, children: [ ... ] }`, which is an awkward structure to query. The result is that when you're working with XML, you almost always end up with a "data API" that's designed specifically for XML (eg. classes representing nodes with getters for attributes and children), whereas with JSON you're generally working with simple nested lists and structs. This introduces relatively much complexity in what's a "hot path" in terms of development effort - every single time you want to interact with the deserialized data (which is all the time!), you have to deal with an XML-specific data structure instead of treating it as "just another source-agnostic pile of structs/objects". The result is tightly coupled code that requires the reader to be familiar with the specific XML API/representation being used, instead of it 1:1 mapping from the serialized data to a language-native data structure. That's not good! While it is true that you are likely to implement a namespace-like mechanism in JSON as well, for open protocols, the difference is that the format itself does not specially define namespaces - which means that the 1:1 mapping always remains true, and it's the protocol developer's choice to eg. reserve a `children` property to contain child nodes, with the understanding that that property then cannot be used for other things anymore. XML deserializers cannot do this; it's entirely possible for XML to exist that looks like `<tag children="yes"><subtag/></tag>`, and therefore there is no possible 1:1 mapping that a deserializer can use that's guaranteed not to make certain data inaccessible. And since child nodes are not represented as an attribute in XML's data model, you cannot expect protocol designers to avoid a specific attribute either. Bottom line: I suspect that this seemingly small design difference has far-reaching second-order effects in how deserializers are implemented, and that that is responsible for most of the pain that people experience in working with XML.

5y ago

andrewshadura 5y ago

> It's 2022 and there is still nothing better for federated messaging. That is untrue. Matrix is undoubtedly much better.

Andrew_nenakhov 5y ago
Lol no. It is a monolithic monster that will never see any other independent server vendor. Matrix is a product with a public API, not a protocol.
- andrewshadura 5y ago
  This is, again, untrue.
  - Andrew_nenakhov 5y ago
    As jhugo said in a sister subthread, it doesn't become true if you repeat it again and again.
jhugo 5y ago
No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. Matrix is basically a case study in how not to design a federated chat protocol. It's bloated, it ignores all prior art and reinvents the wheel everywhere it can, and its excessive complexity means there is unlikely to ever be a wide ecosystem of good-quality implementations (especially of servers). Just because they made a foundation and threw around the word "standard" a lot doesn't mean it deserves to be the standard for chat protocols.
- wusspuss 5y ago
  >No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. Maybe judge not by reading protocol description but by trying and using said protocol, like, chatting with people a lot? With the latter approach you'll notice a very handy feature of Matrix - not losing messages.

easrng 5y ago

JSON with namespaces exists, it's called JSON-LD, and it's used by ActivityPub among others.