7 ms·

Smells like an article from someone that didn’t really USE the XML ecosystem. First, there is modeling ambiguity, too many ways to represent the same data stru

Smells like an article from someone that didn’t really USE the XML ecosystem. First, there is modeling ambiguity, too many ways to represent the same data structure. Which means you can’t parse into native structs but instead into a heavy DOM object and it sucks to interact with it. Then, schemas sound great, until you run into DTD, XSD, and RelaxNG. Relax only exists because XSD is pretty much incomprehensible. Then let’s talk about entity escaping and CDATA. And how you break entire parsers because CDATA is a separate incantation on the DOM. And in practice, XML is always over engineered. It’s the AbstractFactoryProxyBuilder of data formats. SOAP and WSDL are great examples of this, vs looking at a JSON response and simply understanding what it is. I worked with XML and all the tooling around it for a long time. Zero interest in going back. It’s not the angle brackets or the serialization efficiency. It’s all of the above brain damage.

mkozlows 9mo ago
The part where it favorably mentioned namespaces also blew my mind. Namespaces were a constant pain point!
- riffraff 9mo ago
  Namespaces are a cool idea that didn't really seem to pan out in practice.
- masklinn 9mo ago
  Namespaces were fun! But mostly used for over engineering formats and interacted with by idiots who do not give a toss. Shout out to every service that would break as soon as elementtree got involved. And my idiot colleagues who work on EDI.
- pjmlp 9mo ago
  Nope, they were great. Our AOLServer like clone in 2000 used them to great effect in our widget component library.
- VerifiedReports 8mo ago
  I took an XML class as it neared its heyday, and even the teacher was rolling his eyes at the inclusion of namespaces. Amateur hour.
- aezart 8mo ago
  We use Mulesoft where I work, and XML namespaces are a constant issue. We never managed to define an API spec in such a way that the RAML compiler and the APIKit validator would both accept the same payload. In the end we just had to turn off validations in APIkit.
- Mikhail_Edoshin 8mo ago
  Namespaces give you human readable GUIDs as element names. This is important. I agree their implementation and integration is a bit inconvenient.
deleted 9mo ago
[deleted]
bornfreddy 9mo ago
You managed to convey my thoughts exactly, and you only used term "SOAP" once. Kudos! SOAP was terrible everywhere, not just in Nigeria as OP insinuates. And while the idea of XML sounds good, the tools that developed on top of it were mostly atrocious. Good riddance.
locknitpicker 9mo ago
> I worked with XML and all the tooling around it for a long time. Zero interest in going back. It’s not the angle brackets or the serialization efficiency. It’s all of the above brain damage. I remember a decade ago seeing job ads that explicitly requested XML skills. The fact that being able to do something with XML was considered a full time job requiring a specialist says everything there is to be said about XML.
- g-b-r 9mo ago
  They probably didn't mean "doing something with XML", but knowing a lot of its complex ecosystem
nine_k 9mo ago
XML grew from SGML (like HTML did), and it brought from it a bunch of things that are useless outside a markup language. Attributes were a bad idea. Entities were a so-so idea, which became unapologetically terrible when URLs and file references were allowed. CDATA was an interesting idea but an error-prone one, and likely it just did not belong. OTOH namespaces, XSD, XSLT were great, modulo the noisy tags. XSLT was the first purely functional language that enjoyed mass adoption in the industry. (It was also homoiconic, like Lisp, amenable to metaprogramming.) Namespaces were a lifesaver when multiple XML documents from different sources had to be combined. XPath was also quite nice for querying. XML is noisy because of the closing tags, but it also guarantees a level of integrity, and LZ-type compressors, even gzip, are excellent at compacting repeated strings. Importantly, XML is a relatively human-friendly format. It has comments, requires no quoting, no commas between list items, etc. Complexity killed XML. JSON was stupid simple, and thus contained far fewer footguns, which was a very welcome change. It was devised as a serialization format, a bit human-hostile, but mapped ideally to bag-of-named-values structures found in basically any modern language. Now we see XML tools adopted to JSON: JSONSchema, JSONPath, etc. JSON5 (as used in e.g. VSCode) allows for comments, trailing commas and other creature comforts. With tools like that, and dovetailing tools like Pydantic, XML lost any practical edge over JSON it might ever have. What's missing is a widespread replacement for XSLT. Could be a fun project.
- sparqlittlestar 9mo ago
  XSLT 3.0 does JSON https://www.w3.org/TR/xslt-30/#json https://www.w3.org/TR/xslt-30/#json
  - sam_lowry_ 9mo ago
    XSLT ended at 1.1 for me. Everything that was "designed-by-committee" later was subverted to serve the bottom line of Michael Kay enterprises, although I hesitate to attribute to malice the grueling incompetence of the working group at the time.
- wombatpm 9mo ago
  Don’t forget the whole DOM vs SAX processing mess. Big documents would routinely kill parsers by running out of Memory. XSLT was cool. Too bad XSL and Apache-FOP never took off.
wvenable 9mo ago
I read the article and my first thought was it was entirely missing the complexity of XML. It started out relatively simple and easy to understand and most people/programs wrote simple XML that looked a lot like HTML still does. But it didn't take long before XML might well be a binary format for all it matters to us humans looking at it, parsing it, dealing with it. JSON came along and it's simplicity was baked in. Anyone can argue it's not a great format but it forcefully maintains the simplicity that XML lost quite quickly.
- mickael-kerjean 9mo ago
  > It started out relatively simple and easy to understand .... when the specs for a data representation format evolved with XML bombs abilities, it has gone too far in trying to please everyone, and that is probably why JSON won in the long run, it's not perfect but stable and simple without crazy issues you have to worry about when parsing it. If XML had a Torvaldish kind of dictator who can afford to say no, I doubt JSON would have won
tolciho 9mo ago
And of course XML libraries haven't had any security issues (oh look CVE-2025-49796) and certainly would not need to make random network requests for a DTD of "reasonable" complexity. I also dropped XML, and that's after having a website that used XML, XSLT rendering to different output forms, etc. There were discussions at the time (early to mid 2000s) of moving all the config files on unix over to XML. Various softwares probably have the scars of that era and therefore an XML dependency and is that an embiggened attack surface? Also namespaces are super annoying, pretty sure I documented the ughsauce necessary to deal with them somewhere. Thankfully, crickets serenade the faint cries of "Bueller". The contrast with only JSON is far too simplistic; XML got dropped from places where JSON is uninvolved, like why use a relational database when you can have an XML database??? Or those config files on unix are for the most part still not-XML and not-JSON. Or there's various flavors of markdown which do not give you the semi-mythical semantic web but can be banged out easily enough in vi or whatever and don't require schemas and validation or libraries with far too many security problems and I wouldn't write my documentation (these days) using S-expressions anyhow. This being said there probably are places where something that validates strictly is optimal, maybe financial transactions (EDIFACT and XML are different hells, I guess), at least until some cheeky git points out that data can be leaked by encoding with tabs and spaces between the elements. Hopefully your fancy and expensive XML security layer normalizes or removes that whitespace?
ivan_gammel 9mo ago
>First, there is modeling ambiguity, too many ways to represent the same data structure. Which means you can’t parse into native structs but instead into a heavy DOM object and it sucks to interact with it. I don’t get this argument. There exist streaming APIs with convenient mapping. Yes, there can exist schemas with weird structure, but in practice they are uncommon. I have seen a lot of integration formats in XML, never had the need to parse to DOM first.
pjmlp 9mo ago
I used it, and agree 100% with the author. Hence why in 2026, I still hang around programming stacks, like Java and .NET, where XML tooling is great, instead of having to fight with YAML format errors, Norway error, or JSON without basic stuff like comments.
- sam_lowry_ 9mo ago
  Indeed. XML should be compared with YAML, not JSON. While they equal each other in complexity, YAML does not even have namespaces )
  - downsplat 9mo ago
    I guess one thing we can agree with the author is that YAML is technically a piece of crap.
- EdwardDiego 9mo ago
  > YAML format errors This is why I hate (HATE. LET ME TELL YOU HOW MUCH I'VE COME TO HATE YAML SINCE I BEGAN TO WORK WITH K8S) working with Helm charts. As an example from the Helm docs... https://helm.sh/docs/chart_template_guide/yaml_techniques#indenting-and-templates https://helm.sh/docs/chart_template_guide/yaml_techniques#in... > Note how we do the indentation above: indent 2 tells the template engine to indent every line in "myfile.txt" with two spaces. Note that we do not indent that template line. That's because if we did, the file content of the first line would be indented twice. So you end up with YAML that looks weird, and heaven help you if you refactor and now have to adjust all the `indent N` functions to a new value of N. That said, Helm's approach of "YAML, but with Go templating" is the main source of my hatred - why they didn't take the "It's a tree, and this child node is designated to be replaced" approach is something that's always baffled me.
  - imtringued 8mo ago
    YAML is meant to be written by humans. If some lunatic insists on some expression evaluation system, then it should be ${expression} where the YAML file is parsed as is without a template, and the software that reads the YAML file interprets the expression. If you hate YAML instead of Helm for their insane choices, then enjoy barking at the wrong tree for the rest of your life. I've been using application.yml files for 9 years without experiencing a single YAML related issue and I see no reason to switch to any other format. https://www.baeldung.com/spring-boot-yaml-vs-properties https://www.baeldung.com/spring-boot-yaml-vs-properties
pkphilip 9mo ago
For most data that is structured in JSON now, you could have easily done the same in XML using a simple text editor. I agree with the author that XML is very similar to S expressions but with the brackets replaced by closing tags. Parsing XML wasn't complex either. There have been many good libraries for it in pretty much most languages
- jklowden 9mo ago
  If only there was one good library. libxml2 is the leading one, and it has been beleaguered by problems internal and external. It has had ABI instability and been besieged by CVE reports. I agree it shouldn’t be hard. On the evidence, though, it is. I suspect the root problem is lack of tools. Lex and yacc tools for Unicode are relatively scarce. At least that’s what’s set me back from rolling my own.
  - lenkite 8mo ago
    What is wrong with xml-rs ?
badgersnake 9mo ago
I had great experiences with XSD as a contract in systems integration scenarios, particularly with big systems integrators. It's pretty clear whose fault it is when somebodys XML doesn't validate.
- inkyoto 9mo ago
  The issue is that XSD came along much later, and its use did not become binding in XML validation scenarios, hence partial success, even when the XSD-based validation tooling was available at the time. XSD provides a clean abstraction for the technical validation that sits separately from the application / business / processing layers and dramatically increases the chances of a «clean» request reaching the aforementioned layers without having to roll multiple defensive checks in there. Granted, an XSD can become complex very quickly, especially if indulged in too much, but it does not have to be.
jancsika 9mo ago
> First, there is modeling ambiguity, too many ways to represent the same data structure. Boy, are you telling me! Boy are you a person, one of whose attributes is telling me! Boy are you a person whose telling-me attribute is set to true! Boy-who-is-telling-me, this space is left intentionally blank! Out of all the key value pairs, you are the boy key and your adjacent sibling string type value is "Telling Me!" Edit: fixed a CVE
- codeduck 9mo ago
  This is both painfully hilarious and hilariously painful. It might even be hilarious, but my JVM ran out of memory while trying to build the DOM model.
VerifiedReports 8mo ago
He also mentions namespaces as a plus, so credibility is pretty low.
unscaled 8mo ago
> JSON has no such mechanism built into the format. Yes, JSON Schema exists, but it is an afterthought, a third-party addition that never achieved universal adoption. This really seems like it's written by someone who _did not_ use XML back in the day. XSD is no more built-in than JSON Schema is. XSD was first-party (it was promoted by W3C), but it was never a "built-in" component of XML, and there were alternative schema formats. You can perfectly write XML without XSD and back in the heyday of XML in the 2000s, most XML documents did not have XSD. Nowadays most of the remaining XML usages in production rely heavily on XSD, but that's a bit of a survivorship bias. The projects that used ad-hoc XML as configuration files, simple document files or as an interchange format either died out, converted to another format or eventually adopted XSD. Since almost no new projects are choosing XML nowadays, you don't get an influx of new projects that skip the schema part to ship faster, like you get with JSON. When new developers encounter XML, they are generally interacting with long-established systems that have XSD schemas. This situation is purely incidental. If you want to get the same result with JSON, you can just use JSON Schema. But if we somehow magically convince everybody on the planet to ditch JSON and return to XML (please not), we'll get the same situation we have had with JSON, only worse. We'll just get to wear we've been in the early 2000s, and no, this wasn't good.
hinkley 8mo ago
See, I was just gonna say, “what art?” but you put far more wood behind that arrowhead. - XML-DSIG survivor.
imtringued 8mo ago
SOAP is the biggest mindfuck I've ever interacted with. You have a complex and verbose XML based format where you repeat the tag name, but then you realize that the implementations don't care what the parameters are named and just read them in a fixed order. Coming from JSON based APIs this took me extremely long to realize.

mkozlows 9mo ago

The part where it favorably mentioned namespaces also blew my mind. Namespaces were a constant pain point!

riffraff 9mo ago
Namespaces are a cool idea that didn't really seem to pan out in practice.
masklinn 9mo ago
Namespaces were fun! But mostly used for over engineering formats and interacted with by idiots who do not give a toss. Shout out to every service that would break as soon as elementtree got involved. And my idiot colleagues who work on EDI.
pjmlp 9mo ago
Nope, they were great. Our AOLServer like clone in 2000 used them to great effect in our widget component library.
VerifiedReports 8mo ago
I took an XML class as it neared its heyday, and even the teacher was rolling his eyes at the inclusion of namespaces. Amateur hour.
aezart 8mo ago
We use Mulesoft where I work, and XML namespaces are a constant issue. We never managed to define an API spec in such a way that the RAML compiler and the APIKit validator would both accept the same payload. In the end we just had to turn off validations in APIkit.
Mikhail_Edoshin 8mo ago
Namespaces give you human readable GUIDs as element names. This is important. I agree their implementation and integration is a bit inconvenient.

deleted 9mo ago

[deleted]

bornfreddy 9mo ago

You managed to convey my thoughts exactly, and you only used term "SOAP" once. Kudos! SOAP was terrible everywhere, not just in Nigeria as OP insinuates. And while the idea of XML sounds good, the tools that developed on top of it were mostly atrocious. Good riddance.

locknitpicker 9mo ago

> I worked with XML and all the tooling around it for a long time. Zero interest in going back. It’s not the angle brackets or the serialization efficiency. It’s all of the above brain damage. I remember a decade ago seeing job ads that explicitly requested XML skills. The fact that being able to do something with XML was considered a full time job requiring a specialist says everything there is to be said about XML.

g-b-r 9mo ago
They probably didn't mean "doing something with XML", but knowing a lot of its complex ecosystem

nine_k 9mo ago

XML grew from SGML (like HTML did), and it brought from it a bunch of things that are useless outside a markup language. Attributes were a bad idea. Entities were a so-so idea, which became unapologetically terrible when URLs and file references were allowed. CDATA was an interesting idea but an error-prone one, and likely it just did not belong. OTOH namespaces, XSD, XSLT were great, modulo the noisy tags. XSLT was the first purely functional language that enjoyed mass adoption in the industry. (It was also homoiconic, like Lisp, amenable to metaprogramming.) Namespaces were a lifesaver when multiple XML documents from different sources had to be combined. XPath was also quite nice for querying. XML is noisy because of the closing tags, but it also guarantees a level of integrity, and LZ-type compressors, even gzip, are excellent at compacting repeated strings. Importantly, XML is a relatively human-friendly format. It has comments, requires no quoting, no commas between list items, etc. Complexity killed XML. JSON was stupid simple, and thus contained far fewer footguns, which was a very welcome change. It was devised as a serialization format, a bit human-hostile, but mapped ideally to bag-of-named-values structures found in basically any modern language. Now we see XML tools adopted to JSON: JSONSchema, JSONPath, etc. JSON5 (as used in e.g. VSCode) allows for comments, trailing commas and other creature comforts. With tools like that, and dovetailing tools like Pydantic, XML lost any practical edge over JSON it might ever have. What's missing is a widespread replacement for XSLT. Could be a fun project.

sparqlittlestar 9mo ago
XSLT 3.0 does JSON https://www.w3.org/TR/xslt-30/#json https://www.w3.org/TR/xslt-30/#json
- sam_lowry_ 9mo ago
  XSLT ended at 1.1 for me. Everything that was "designed-by-committee" later was subverted to serve the bottom line of Michael Kay enterprises, although I hesitate to attribute to malice the grueling incompetence of the working group at the time.
wombatpm 9mo ago
Don’t forget the whole DOM vs SAX processing mess. Big documents would routinely kill parsers by running out of Memory. XSLT was cool. Too bad XSL and Apache-FOP never took off.

wvenable 9mo ago

I read the article and my first thought was it was entirely missing the complexity of XML. It started out relatively simple and easy to understand and most people/programs wrote simple XML that looked a lot like HTML still does. But it didn't take long before XML might well be a binary format for all it matters to us humans looking at it, parsing it, dealing with it. JSON came along and it's simplicity was baked in. Anyone can argue it's not a great format but it forcefully maintains the simplicity that XML lost quite quickly.

mickael-kerjean 9mo ago
> It started out relatively simple and easy to understand .... when the specs for a data representation format evolved with XML bombs abilities, it has gone too far in trying to please everyone, and that is probably why JSON won in the long run, it's not perfect but stable and simple without crazy issues you have to worry about when parsing it. If XML had a Torvaldish kind of dictator who can afford to say no, I doubt JSON would have won

tolciho 9mo ago

And of course XML libraries haven't had any security issues (oh look CVE-2025-49796) and certainly would not need to make random network requests for a DTD of "reasonable" complexity. I also dropped XML, and that's after having a website that used XML, XSLT rendering to different output forms, etc. There were discussions at the time (early to mid 2000s) of moving all the config files on unix over to XML. Various softwares probably have the scars of that era and therefore an XML dependency and is that an embiggened attack surface? Also namespaces are super annoying, pretty sure I documented the ughsauce necessary to deal with them somewhere. Thankfully, crickets serenade the faint cries of "Bueller". The contrast with only JSON is far too simplistic; XML got dropped from places where JSON is uninvolved, like why use a relational database when you can have an XML database??? Or those config files on unix are for the most part still not-XML and not-JSON. Or there's various flavors of markdown which do not give you the semi-mythical semantic web but can be banged out easily enough in vi or whatever and don't require schemas and validation or libraries with far too many security problems and I wouldn't write my documentation (these days) using S-expressions anyhow. This being said there probably are places where something that validates strictly is optimal, maybe financial transactions (EDIFACT and XML are different hells, I guess), at least until some cheeky git points out that data can be leaked by encoding with tabs and spaces between the elements. Hopefully your fancy and expensive XML security layer normalizes or removes that whitespace?

ivan_gammel 9mo ago

>First, there is modeling ambiguity, too many ways to represent the same data structure. Which means you can’t parse into native structs but instead into a heavy DOM object and it sucks to interact with it. I don’t get this argument. There exist streaming APIs with convenient mapping. Yes, there can exist schemas with weird structure, but in practice they are uncommon. I have seen a lot of integration formats in XML, never had the need to parse to DOM first.

pjmlp 9mo ago

I used it, and agree 100% with the author. Hence why in 2026, I still hang around programming stacks, like Java and .NET, where XML tooling is great, instead of having to fight with YAML format errors, Norway error, or JSON without basic stuff like comments.

sam_lowry_ 9mo ago
Indeed. XML should be compared with YAML, not JSON. While they equal each other in complexity, YAML does not even have namespaces )
- downsplat 9mo ago
  I guess one thing we can agree with the author is that YAML is technically a piece of crap.
EdwardDiego 9mo ago
> YAML format errors This is why I hate (HATE. LET ME TELL YOU HOW MUCH I'VE COME TO HATE YAML SINCE I BEGAN TO WORK WITH K8S) working with Helm charts. As an example from the Helm docs... https://helm.sh/docs/chart_template_guide/yaml_techniques#indenting-and-templates https://helm.sh/docs/chart_template_guide/yaml_techniques#in... > Note how we do the indentation above: indent 2 tells the template engine to indent every line in "myfile.txt" with two spaces. Note that we do not indent that template line. That's because if we did, the file content of the first line would be indented twice. So you end up with YAML that looks weird, and heaven help you if you refactor and now have to adjust all the `indent N` functions to a new value of N. That said, Helm's approach of "YAML, but with Go templating" is the main source of my hatred - why they didn't take the "It's a tree, and this child node is designated to be replaced" approach is something that's always baffled me.
- imtringued 8mo ago
  YAML is meant to be written by humans. If some lunatic insists on some expression evaluation system, then it should be ${expression} where the YAML file is parsed as is without a template, and the software that reads the YAML file interprets the expression. If you hate YAML instead of Helm for their insane choices, then enjoy barking at the wrong tree for the rest of your life. I've been using application.yml files for 9 years without experiencing a single YAML related issue and I see no reason to switch to any other format. https://www.baeldung.com/spring-boot-yaml-vs-properties https://www.baeldung.com/spring-boot-yaml-vs-properties

pkphilip 9mo ago

For most data that is structured in JSON now, you could have easily done the same in XML using a simple text editor. I agree with the author that XML is very similar to S expressions but with the brackets replaced by closing tags. Parsing XML wasn't complex either. There have been many good libraries for it in pretty much most languages

jklowden 9mo ago
If only there was one good library. libxml2 is the leading one, and it has been beleaguered by problems internal and external. It has had ABI instability and been besieged by CVE reports. I agree it shouldn’t be hard. On the evidence, though, it is. I suspect the root problem is lack of tools. Lex and yacc tools for Unicode are relatively scarce. At least that’s what’s set me back from rolling my own.
- lenkite 8mo ago
  What is wrong with xml-rs ?

badgersnake 9mo ago

I had great experiences with XSD as a contract in systems integration scenarios, particularly with big systems integrators. It's pretty clear whose fault it is when somebodys XML doesn't validate.

inkyoto 9mo ago
The issue is that XSD came along much later, and its use did not become binding in XML validation scenarios, hence partial success, even when the XSD-based validation tooling was available at the time. XSD provides a clean abstraction for the technical validation that sits separately from the application / business / processing layers and dramatically increases the chances of a «clean» request reaching the aforementioned layers without having to roll multiple defensive checks in there. Granted, an XSD can become complex very quickly, especially if indulged in too much, but it does not have to be.

jancsika 9mo ago

> First, there is modeling ambiguity, too many ways to represent the same data structure. Boy, are you telling me! Boy are you a person, one of whose attributes is telling me! Boy are you a person whose telling-me attribute is set to true! Boy-who-is-telling-me, this space is left intentionally blank! Out of all the key value pairs, you are the boy key and your adjacent sibling string type value is "Telling Me!" Edit: fixed a CVE

codeduck 9mo ago
This is both painfully hilarious and hilariously painful. It might even be hilarious, but my JVM ran out of memory while trying to build the DOM model.

VerifiedReports 8mo ago

He also mentions namespaces as a plus, so credibility is pretty low.

unscaled 8mo ago

> JSON has no such mechanism built into the format. Yes, JSON Schema exists, but it is an afterthought, a third-party addition that never achieved universal adoption. This really seems like it's written by someone who _did not_ use XML back in the day. XSD is no more built-in than JSON Schema is. XSD was first-party (it was promoted by W3C), but it was never a "built-in" component of XML, and there were alternative schema formats. You can perfectly write XML without XSD and back in the heyday of XML in the 2000s, most XML documents did not have XSD. Nowadays most of the remaining XML usages in production rely heavily on XSD, but that's a bit of a survivorship bias. The projects that used ad-hoc XML as configuration files, simple document files or as an interchange format either died out, converted to another format or eventually adopted XSD. Since almost no new projects are choosing XML nowadays, you don't get an influx of new projects that skip the schema part to ship faster, like you get with JSON. When new developers encounter XML, they are generally interacting with long-established systems that have XSD schemas. This situation is purely incidental. If you want to get the same result with JSON, you can just use JSON Schema. But if we somehow magically convince everybody on the planet to ditch JSON and return to XML (please not), we'll get the same situation we have had with JSON, only worse. We'll just get to wear we've been in the early 2000s, and no, this wasn't good.

hinkley 8mo ago

See, I was just gonna say, “what art?” but you put far more wood behind that arrowhead. - XML-DSIG survivor.

imtringued 8mo ago

SOAP is the biggest mindfuck I've ever interacted with. You have a complex and verbose XML based format where you repeat the tag name, but then you realize that the implementations don't care what the parameters are named and just read them in a fixed order. Coming from JSON based APIs this took me extremely long to realize.