Live data from Hacker News

The lost art of XML

marcosmagueta.com

131–140 of 179 posts

Re: The lost art of XML

#131

This is performance art, right? The very first bullet point it starts with is extolling the merits of XSD. Even back in the day when XML was huge, XSD was widely recognized as a monstrosity and a boondoggle -- the real XMLheads were trying to make RELAX NG happen, but XSD got jammed through because it was needed for all those monstrous WS-* specs. XML did some good things for its day, but no, we abandoned it for very…

Also as someone else pointed out the same complaints that JSON Schema "isn't in the standard, it's a separate standard" apply to XSD. It is still a different standard even though during the height of XML mania it sometimes seemed like XSD was inseperable. XML did have DTD baked in, and maybe the author meant DTD in that section, but that was even worse than XSD (and again both were why RELAX NG happened).

Re: The lost art of XML

#132
post #40

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…

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…

> 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.

That's exactly what I wanted to say. The author talks as if XML was well designed to represent structured data, but it was not, it grew out of the idea of marking up text, which is a completely different problem. The hilarious part is that he doesn't recognize the problem when he gives his example of "or with attributes".

The other thing, is that the JSON model doesn't just give you a free parser/serializer in JavaScript. It actually maps to the basic data model of the entire generation of dynamic languages that the Web grew on: perl, Python, JS, PHP and Ruby. Arrays and maps are the basic way to represent structured data in these languages, and JSON just serializes that. Which means that getting data in and out of your language is just a single line.

The author seems to think that XML maps a proper conceptual model and JSON doesn't, but the model of "nodes with attributes and content" is a worse match for structured data than JSON's model of "arrays and maps of values".

Other than that, it's really a question of how much tooling you want to use. Both JSON and XML grew entire ecosystems of it, and nowadays if you want to read your JSON according to a schema into typed objects, you can, and for any good-sized project, you probably should.

Also: > There are cases where other formats are appropriate: small data transfers between cooperating services and scenarios where schema validation would be overkill.

That's actually most of the cases for your average web dev!

Re: The lost art of XML

#133
post #40

Earlier quoted context omitted.

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…

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.

It still works well in the appropriate settings. LibreOffice (nee OpenOffice) uses ODF, an XML format, for its document files, and it has been working nicely enough for a long time.

Re: The lost art of XML

#134
post #83

Earlier quoted context omitted.

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.

Indeed. XML should be compared with YAML, not JSON. While they equal each other in complexity, YAML does not even have namespaces )

I guess one thing we can agree with the author is that YAML is technically a piece of crap.

Re: The lost art of XML

#136
Schemas? Oh you mean the one where Double doesn't inherent from Decimal? Year numbers with attached timezones? Author has not looked at this insanity for more than five seconds.

Re: The lost art of XML

#137

Earlier quoted context omitted.

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.

It still works well in the appropriate settings. LibreOffice (nee OpenOffice) uses ODF, an XML format, for its document files, and it has been working nicely enough for a long time.

MS Office's own XSLX and DOCX formats are trees of XML files, zipped.

Re: The lost art of XML

#138
post #83

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…

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.

> 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#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.

Re: The lost art of XML

#139
post #40

Earlier quoted context omitted.

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…

> and it brought from it a bunch of things that are useless outside a markup language It is a markup language. The mistake was trying to use it for anything else.

amen

Re: The lost art of XML

#140
post #85

Earlier quoted context omitted.

Any server rendered HTML site or application?

Never used it on ASP.NET or Java EE/Jakarta EE/Spring.

Were you exclusively building SPAs with all of those frameworks? If you ever rendered state/content to HTML on the server you were using HATEOAS (and REST) principles.
Post reply on HN