4 ms·

In my experience, anything XML-related seems to be the product of simplicity-hating architecture astronauts with zero consideration for efficiency, possibly as

In my experience, anything XML-related seems to be the product of simplicity-hating architecture astronauts with zero consideration for efficiency, possibly as a way of justifying their existence and continued employment. Standards based on ASN.1 get a lot of hate (X.509 etc.) but I'd rather work with that than XML.

amluto 2y ago
I find XML to be perfectly fine as a markup language. I once set up a system to generate logs as XML elements and display them prettily with XSLT. It was delightful! Using XML as an interchange format for things intended to be read by a machine is not so great. Don’t use it where you actually want something more like protobuf.
- bawolff 2y ago
  XML isnt great for that, but the xml part is the least of the concerns. XSignature and SAML are insane specs, and would still be insane if the underlying presentation language wasnt xml (i mean, then you wouldnt be using xsignature, but if you made sone xsignature like thing for a different presentation language, it would still be crazy)
  - amluto 2y ago
    Signatures in XML are nuts. So is all the mess built around RPC in XML, although IMO that’s not as bad as signatures. But the problem with signatures has nothing to do with XML per se in my opinion. I could just as easily come up with a similarly poor signature scheme in HTML (snicker), nasty C structs with endian issues, MIME, or even plain English. Hah, someone should make a signature scheme meant to be verified by an LLM that parses it and calls out to a helper to do the actual math :) Seriously, though, signing XML well is easy. Take some XML, serialize it to bytes, sign with libsodium, and transport the bytes of XML and the bytes of signature. But do not get cute and transport the signed XML as a subtree in another XML document: the bytes must bytes until the signature is verified. You could maybe get away with sticking it in another document as CDATA [0], but base64 would be better, since you basically can’t screw it up. And it’s entirely possible to screw even this up JOSE-style if you lose track of what a “key” is. DO NOT have the signed (document, signature) tuple specify the signature algorithm or parameters. All of that is part of the public key, which the verifier (obviously) needs to acquire out of band. [0] Someone may pwn, or at least massively confuse, you if you do this. Imagine what happens if the inner and outer documents have different character encodings.
- jahewson 2y ago
  I like your take and I think it is demonstrated by the fact that JSX is nice and YAML is awful.
tannhaeuser 2y ago
You're not wrong. The amount of fields of use where XML is used bogusly which have nothing to do with markup is truly staggering. XML signing and relying on canonical XML serialization for it is just peak and something else. The sad thing is that XML was meant as a simplification over full SGML for delivery of markup on the web. Specifically, XML is always fully tagged (doesn't make use of tag inference), and does neither have empty ("void") elements nor short forms for attributes such as in <option selected>. Thus XML never needs markup declarations for special per-element or per-attribute parsing rules. This was done to facilitate newer vocabularies next to HTML like SVG and MathML. But soon enough, folks took the XML specification as an invitation for complexity and a self-serving spec circus: namespaces, XInclude (as a bogus replacement for entity expansion), XQuery, XSLT, XML Schema as a super-verbose replacement for DTDs using XML itself, etc. XHTML 2 was the largest failure and turning point, introducing not just a new vocabulary, but trying to reinvent how browsers work in a design-by-comittee fashion. It could be said that XHTML took W3C down along with it. For message payloads in large and long-term multi-party projects (governments, finance/payments, healthcare, etc.), I'm however not sure the alternatives (JSON-over-HTTP and the idiotic quasi-religious apeal to misunderstood "REST" semantics) is really helping. XML Schema, while in part overkill and unused (substitution groups), certainly has facilitated separating service interface from service implementation, multiple generations and multiple implementations, test cases bases, and other long-term maintenance goals.
- eftpotrm 2y ago
  I'm not going to argue that XML hasn't been used badly and excessively in a lot of places, it really has, and using every part of it religiously will tie you in knots, fast. But I can't help noticing that Json is gaining more and more XML-like functionality through things like schemas and JsonPath, as people slowly realise why XML had those functions they're now having to replace. I'm a long way from convinced that all the engineering effort to switch was actually beneficial.
  - aversis_ 2y ago
    Devs just love reinventing the wheel every few years. Maybe we should switch to CSV next just for fun.
zaik 2y ago
XMPP is still a simple and efficient chat protocol. But it makes sure to only allow a sane subset of XML.
- mdaniel 2y ago
  > and efficient citation needed https://xmpp.org/rfcs/rfc6121.html#session https://xmpp.org/rfcs/rfc6121.html#session
  - zaik 2y ago
    Almost all steps in this example session are optional. But even clients that do everything are still more efficient than most other chat apps people use: https://blog.lewman.com/internet-messaging-versus-congested-network.html https://blog.lewman.com/internet-messaging-versus-congested-...
- userbinator 2y ago
  IRC and (early versions of) MSNP are far simpler and more efficient.
gwervc 2y ago
You are throwing the baby with the bath water. XML is fine, even if it has some gotcha. Astronauts will go wild with any tech at their disposal (I'm seeing it every day at work with .net and JSON).
zerkten 2y ago
This is very true. You only have to look at the list authors/editors of the specs from Oasis to see that they square up with the individuals identified by Joel in https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect.... If XML was removed, these specs wouldn't have been much better. The motivation of the companies sponsoring specs was to build something that sold more enterprise middleware and identity servers. This was never going to be attractive to the individuals working with IETF, or the people working on web standards who'd create WHATWG (I know SAML isn't their domain.) Many readers here also won't be aware of how web services, SOAP, and XML were the AI hype of the time. These were getting pushed into every kind of solution. At the same time, the alternative options for document and serialization formats weren't ubiquitous, so having XML everywhere was somewhat pragmatic for the average developer. I can't imagine ASP (or early-.NET) developers trying to deal with ASN.1.
darby_nine 2y ago
> In my experience, anything XML-related seems to be the product of simplicity-hating architecture astronauts with zero consideration for efficiency, possibly as a way of justifying their existence and continued employment. I am very confused by people who have emotional reactions to technologies. XML has a number of capabilities that are very difficult to represent in other documents without creating an unreadable mess. XML is more than just the worst SOAP api you've used.
- AtlasBarfed 2y ago
  ......such as? Xml is a hierarchical days structure that has less data hinting to parsers /serializes than json. Please don't say namespaces. Broke xpath and other parsing techs. Attrs vs tags? Cdata? Any one remember ibm web services being all cdata tags?
  - consteval 2y ago
    The existence of closing tags makes tree structures much more convenient and ergonomical to represent. Also the supporting XML tech is quite nice. Schema validation and translation is simple. It's also much simpler to parse.
- lcnPylGDnU4H9OF 2y ago
  > I am very confused by people who have emotional reactions to technologies. Given the phrasing ("simplicity-hating architecture astronauts"), I suspect they're having an emotional reaction to a colleague who, at some point, advocated for their team's use of XML. Which I honestly think is slightly justified if their colleague's advocacy was thoughtless or otherwise unreasonable. Maybe JSON would actually work better for what they were doing. Of course, that said, I also say it's "slightly" justified because good ol' XML did nothing wrong.

amluto 2y ago

I find XML to be perfectly fine as a markup language. I once set up a system to generate logs as XML elements and display them prettily with XSLT. It was delightful! Using XML as an interchange format for things intended to be read by a machine is not so great. Don’t use it where you actually want something more like protobuf.

bawolff 2y ago
XML isnt great for that, but the xml part is the least of the concerns. XSignature and SAML are insane specs, and would still be insane if the underlying presentation language wasnt xml (i mean, then you wouldnt be using xsignature, but if you made sone xsignature like thing for a different presentation language, it would still be crazy)
- amluto 2y ago
  Signatures in XML are nuts. So is all the mess built around RPC in XML, although IMO that’s not as bad as signatures. But the problem with signatures has nothing to do with XML per se in my opinion. I could just as easily come up with a similarly poor signature scheme in HTML (snicker), nasty C structs with endian issues, MIME, or even plain English. Hah, someone should make a signature scheme meant to be verified by an LLM that parses it and calls out to a helper to do the actual math :) Seriously, though, signing XML well is easy. Take some XML, serialize it to bytes, sign with libsodium, and transport the bytes of XML and the bytes of signature. But do not get cute and transport the signed XML as a subtree in another XML document: the bytes must bytes until the signature is verified. You could maybe get away with sticking it in another document as CDATA [0], but base64 would be better, since you basically can’t screw it up. And it’s entirely possible to screw even this up JOSE-style if you lose track of what a “key” is. DO NOT have the signed (document, signature) tuple specify the signature algorithm or parameters. All of that is part of the public key, which the verifier (obviously) needs to acquire out of band. [0] Someone may pwn, or at least massively confuse, you if you do this. Imagine what happens if the inner and outer documents have different character encodings.
jahewson 2y ago
I like your take and I think it is demonstrated by the fact that JSX is nice and YAML is awful.

tannhaeuser 2y ago

You're not wrong. The amount of fields of use where XML is used bogusly which have nothing to do with markup is truly staggering. XML signing and relying on canonical XML serialization for it is just peak and something else. The sad thing is that XML was meant as a simplification over full SGML for delivery of markup on the web. Specifically, XML is always fully tagged (doesn't make use of tag inference), and does neither have empty ("void") elements nor short forms for attributes such as in <option selected>. Thus XML never needs markup declarations for special per-element or per-attribute parsing rules. This was done to facilitate newer vocabularies next to HTML like SVG and MathML. But soon enough, folks took the XML specification as an invitation for complexity and a self-serving spec circus: namespaces, XInclude (as a bogus replacement for entity expansion), XQuery, XSLT, XML Schema as a super-verbose replacement for DTDs using XML itself, etc. XHTML 2 was the largest failure and turning point, introducing not just a new vocabulary, but trying to reinvent how browsers work in a design-by-comittee fashion. It could be said that XHTML took W3C down along with it. For message payloads in large and long-term multi-party projects (governments, finance/payments, healthcare, etc.), I'm however not sure the alternatives (JSON-over-HTTP and the idiotic quasi-religious apeal to misunderstood "REST" semantics) is really helping. XML Schema, while in part overkill and unused (substitution groups), certainly has facilitated separating service interface from service implementation, multiple generations and multiple implementations, test cases bases, and other long-term maintenance goals.

eftpotrm 2y ago
I'm not going to argue that XML hasn't been used badly and excessively in a lot of places, it really has, and using every part of it religiously will tie you in knots, fast. But I can't help noticing that Json is gaining more and more XML-like functionality through things like schemas and JsonPath, as people slowly realise why XML had those functions they're now having to replace. I'm a long way from convinced that all the engineering effort to switch was actually beneficial.
- aversis_ 2y ago
  Devs just love reinventing the wheel every few years. Maybe we should switch to CSV next just for fun.

zaik 2y ago

XMPP is still a simple and efficient chat protocol. But it makes sure to only allow a sane subset of XML.

mdaniel 2y ago
> and efficient citation needed https://xmpp.org/rfcs/rfc6121.html#session https://xmpp.org/rfcs/rfc6121.html#session
- zaik 2y ago
  Almost all steps in this example session are optional. But even clients that do everything are still more efficient than most other chat apps people use: https://blog.lewman.com/internet-messaging-versus-congested-network.html https://blog.lewman.com/internet-messaging-versus-congested-...
userbinator 2y ago
IRC and (early versions of) MSNP are far simpler and more efficient.

gwervc 2y ago

You are throwing the baby with the bath water. XML is fine, even if it has some gotcha. Astronauts will go wild with any tech at their disposal (I'm seeing it every day at work with .net and JSON).

zerkten 2y ago

This is very true. You only have to look at the list authors/editors of the specs from Oasis to see that they square up with the individuals identified by Joel in https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect.... If XML was removed, these specs wouldn't have been much better. The motivation of the companies sponsoring specs was to build something that sold more enterprise middleware and identity servers. This was never going to be attractive to the individuals working with IETF, or the people working on web standards who'd create WHATWG (I know SAML isn't their domain.) Many readers here also won't be aware of how web services, SOAP, and XML were the AI hype of the time. These were getting pushed into every kind of solution. At the same time, the alternative options for document and serialization formats weren't ubiquitous, so having XML everywhere was somewhat pragmatic for the average developer. I can't imagine ASP (or early-.NET) developers trying to deal with ASN.1.

darby_nine 2y ago

> In my experience, anything XML-related seems to be the product of simplicity-hating architecture astronauts with zero consideration for efficiency, possibly as a way of justifying their existence and continued employment. I am very confused by people who have emotional reactions to technologies. XML has a number of capabilities that are very difficult to represent in other documents without creating an unreadable mess. XML is more than just the worst SOAP api you've used.

AtlasBarfed 2y ago
......such as? Xml is a hierarchical days structure that has less data hinting to parsers /serializes than json. Please don't say namespaces. Broke xpath and other parsing techs. Attrs vs tags? Cdata? Any one remember ibm web services being all cdata tags?
- consteval 2y ago
  The existence of closing tags makes tree structures much more convenient and ergonomical to represent. Also the supporting XML tech is quite nice. Schema validation and translation is simple. It's also much simpler to parse.
lcnPylGDnU4H9OF 2y ago
> I am very confused by people who have emotional reactions to technologies. Given the phrasing ("simplicity-hating architecture astronauts"), I suspect they're having an emotional reaction to a colleague who, at some point, advocated for their team's use of XML. Which I honestly think is slightly justified if their colleague's advocacy was thoughtless or otherwise unreasonable. Maybe JSON would actually work better for what they were doing. Of course, that said, I also say it's "slightly" justified because good ol' XML did nothing wrong.