Do you hate XML? (2010) • Hacker News Board

Re: Do you hate XML? (2010)

#31

Post by wombatpm » Sun, Jul 05, 2026, 7:55 PM UTC

actionfromafar wrote: post #5

kccqzy wrote: post #2

In my opinion, the reason people hate XML is because of what M signifies: it is a markup language and most of the time we don’t need a markup language. Markup languages are great for rich text documents. They are just not a good fit for representing data. The markup-nature of XML introduces unnecessary choice in whether to use an attribute or a child element to represent data; for HTML such ambiguity doesn’t actually…

YAML made me not hate XML.

XML is like violence. If it’s not solving your problem, you need to use more.

Re: Do you hate XML? (2010)

#32

Post by davidpapermill » Sun, Jul 05, 2026, 7:57 PM UTC

Last year we chose XML as the basis for our document language.

It's been a good choice for designing a new language, but we've been really surprised by the poor quality of the available parsers. We figured it would be a solved problem, but we'll be writing our own at some point.

Re: Do you hate XML? (2010)

#33

Post by dgrunwald » Sun, Jul 05, 2026, 8:01 PM UTC

kccqzy wrote: post #2

In my opinion, the reason people hate XML is because of what M signifies: it is a markup language and most of the time we don’t need a markup language. Markup languages are great for rich text documents. They are just not a good fit for representing data. The markup-nature of XML introduces unnecessary choice in whether to use an attribute or a child element to represent data; for HTML such ambiguity doesn’t actually…

> Furthermore parsing JSON or YAML gives you the basic data types like lists and dictionaries. Parsing XML gives you an AST that requires a lot more effort to turn into data in your domain.

More precisely: in XML, elements (nodes) are named/labeled. ("node-labeled graph") In JSON, keys (edges) are named. ("edge-labeled graph")

In programming, we need names for the fields in our structures (edges between objects), so JSON is a much better match than XML (which needs contortions to handle this use case -- e.g. by having nesting levels alternate between element=node and element=edge). Only in some object-oriented cases (which derived class should the deserializer construct?) do you care about node labels -- but usually that's in addition to edge labels, so a "_type" key in JSON is still easier than XML.

Re: Do you hate XML? (2010)

#34

Post by janci » Sun, Jul 05, 2026, 8:02 PM UTC

My reasons to hate XML:

- element vs attribute ambiguity

- model of the document does not fit nicely to programming model of structs, dicts and arrays

- too many complexities (entities, cdata, parser directives)

- cardinality unknown without schema (is that a single value, or an array that just happens to have one element)

- order of elements may or may not be significant depending on schema

- not really extensible if the original schema does not explicitly allow for extensibility

- some types of valid XML documents are not representable by a schema (e.g. any number of different elements in any order)

- verbosity

- namespace identifiers being URIs that may or may not be resolvable

What I want for general data exchange is JSON with comments and sane namespaces.

Edit: line wraps

Re: Do you hate XML? (2010)

#35

Post by TedDoesntTalk » Sun, Jul 05, 2026, 8:04 PM UTC

kccqzy wrote: post #2

In my opinion, the reason people hate XML is because of what M signifies: it is a markup language and most of the time we don’t need a markup language. Markup languages are great for rich text documents. They are just not a good fit for representing data. The markup-nature of XML introduces unnecessary choice in whether to use an attribute or a child element to represent data; for HTML such ambiguity doesn’t actually…

Cardinality is the easy way to resolve this. If the data has a cardinality of 1, it should be an attribute. If cardinality > 1, it should be a child element/node.

Re: Do you hate XML? (2010)

#36

Post by dtech » Sun, Jul 05, 2026, 8:06 PM UTC

crispyambulance wrote: post #3

XML was a good, well-intentioned idea. The problem, IMHO, was that rampant "xml-abuse" in the naughts. ws-* standards and over-engineered garbage like SOAP ("complex object access protocol") made people loathe XML. I did like JAXB in Java, XLST, schemas, XPATH. Never got into XSL, but it seemed like good thing too. It worked best when your tooling manipulated it for you or at least helped you in an intelligent way. M…

It's non-trivial to implement XML parser in a secure way, many stdlib ones are insecure by default. That should just not be a thing. XML has a bunch of vulnerabilities very specific to it, XXE is the most well known one, but you also have a bunch of DoSes due to expansions and XPath injection etc.

An object serialization format should not have a bunch of footguns and vulnerability categories specific to it.

Re: Do you hate XML? (2010)

#37

Post by derriz » Sun, Jul 05, 2026, 8:07 PM UTC

I dislike it because it failed in such a fundamental way as a way to represent a document; you cannot, in general, reliably determine what characters the bytes in an XML file represent - the best a general XML processor can do is guess.

Re: Do you hate XML? (2010)

#38

Post by conartist6 » Sun, Jul 05, 2026, 8:08 PM UTC

dgrunwald wrote: post #33

kccqzy wrote: post #2

In my opinion, the reason people hate XML is because of what M signifies: it is a markup language and most of the time we don’t need a markup language. Markup languages are great for rich text documents. They are just not a good fit for representing data. The markup-nature of XML introduces unnecessary choice in whether to use an attribute or a child element to represent data; for HTML such ambiguity doesn’t actually…

> Furthermore parsing JSON or YAML gives you the basic data types like lists and dictionaries. Parsing XML gives you an AST that requires a lot more effort to turn into data in your domain. More precisely: in XML, elements (nodes) are named/labeled. ("node-labeled graph") In JSON, keys (edges) are named. ("edge-labeled graph") In programming, we need names for the fields in our structures (edges between objects), so…

CSTML gets the best of both worlds https://docs.bablr.org/guides/cstml

Re: Do you hate XML? (2010)

#39

Post by ExoticPearTree » Sun, Jul 05, 2026, 8:11 PM UTC

kccqzy wrote: post #28

sfn42 wrote: post #18

Earlier quoted context omitted.

Not really. In C# I use a parsing library for which I just write a class and then the library automatically serializes the JSON into an instance of that class. I can do the same thing with XML. Of course it doesn't necessarily go that smoothly with all xml, but as long as the xml is fairly simple like a JSON document would be it's totally fine. It's only when you start to use all the features of xml that don't fit ne…

That is actually a good approach that I have also used a lot: let the parsing library handle everything including the serialization and deserialization. But if you do that, why do you care that behind the scenes it is using JSON or XML or protobuf or something else?

Because at some point you have to debug stuff. And JSON is easier to read than XML to figure out where a problem might be.

Re: Do you hate XML? (2010)

#40

Post by HarHarVeryFunny » Sun, Jul 05, 2026, 8:14 PM UTC

kccqzy wrote: post #2

In my opinion, the reason people hate XML is because of what M signifies: it is a markup language and most of the time we don’t need a markup language. Markup languages are great for rich text documents. They are just not a good fit for representing data. The markup-nature of XML introduces unnecessary choice in whether to use an attribute or a child element to represent data; for HTML such ambiguity doesn’t actually…

Attributes are intended to hold metadata, not data. It's not the fault of the format if someone chose to use it in a poor way.

You also need to distinguish the format itself from the various libraries that may be available to parse/process it in a given language. It doesn't always make sense, even when it's an option, to let the tail wag the dog and choose a language just because it has a nice library for something.

> Furthermore parsing JSON or YAML gives you the basic data types like lists and dictionaries

Well, maybe some library for some language does that, and if that is the language you are using, and that is all you need, then I suppose you are in luck. More generally you may want to use a format like XML or JSON to hold user defined types, which rather levels the playing field since there are few good libraries for this in any language,and you may need to roll your own (been there, done that).