At least XML is hated for the wrong reasons (e.g. verbosity, esthetics) most of the time. There was for sure an era where it was overused (see Apache Cocoon from 2006 https://en.wikipedia.org/wiki/Apache_Cocoon ). But XML is still a pretty good format to exchange (and store) data and make sure the data conforms to a certain schema. JSON Schema in comparison is not nearly as powerful.
1. What, in your view, are the right reasons to hate XML? 2. To me, verbosity and aesthetics seem like perfectly valid reasons to hate XML. Once you learn S expressions, XML looks disgusting . They implemented half of Common Lisp in a markup language.
Do you hate XML? (2010)
81–90 of 99 posts
Re: Do you hate XML? (2010)
#82Earlier quoted context omitted.
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.…
Again we come back to it being a markup language. In markup, it's usually pretty clear what is data and metadata: hello world and not bold hello world because you don't want the word "bold" to literally appear in the document. In structured data, the distinction is redundant.
For example, XML itself doesn't have types, so maybe you need to use attributes to store the data type (e.g. what if you need to do to lossless JSON XML conversion).
Re: Do you hate XML? (2010)
#83In 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.
I’ve come to realise that it’s almost always a mistake to assume a cardinality of 1, unless it’s something that is defined to be artificially unique like the id attribute.
Re: Do you hate XML? (2010)
#84Earlier quoted context omitted.
1. What, in your view, are the right reasons to hate XML? 2. To me, verbosity and aesthetics seem like perfectly valid reasons to hate XML. Once you learn S expressions, XML looks disgusting . They implemented half of Common Lisp in a markup language.
The right reason to hate XML would be some technical limitation or technical issues with it. But XML works quite well and is reasonable powerful. So the complaints usually boil down to: It is ugly and verbose.
I mean, it's also a taste issue. The verboseness is ugly. I don't like it.
But it's a technical issue. You have to parse all of that verbosity, every time you read it, which is inefficient. If you're hand-generating it, which happens in the development process, you have to get all of that verbosity right, or it doesn't work. These days nobody hand-rolls a parser, but the interface to the parser is more clumsy than it needs to be, because it mirrors the structure of XML.
Re: Do you hate XML? (2010)
#85Earlier quoted context omitted.
> Why is the country name an attribute but not the rank? Perhaps because it's an example of what is possible in XML and how to parse it, and not, in fact, a particularly good or canonical example of XML?
It's a very typical example. The real world does look like this.
Either way the context of that comment is "why does XML do this?" when in fact XML, itself, does not.
It allows both data and metadata; this is not a flaw, because it is not a pure data format.
You can choose to use those features correctly or incorrectly, and how you choose to do it is application-specific, because it is a format that is capable of producing both structured and semi-structured markup. Sometimes an ID is data; sometimes in the context of an application it is only metadata. It depends.
And that is putting aside that this complaint was used to mount a partial defence of YAML, which is one of the worst things the open source community has ever done to the world. YAML is never the answer.
Re: Do you hate XML? (2010)
#86XML 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)
#87Re: Do you hate XML? (2010)
#88I 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.
By default XML is either UTF-8 or 16, any other encoding has to be identified either through metadata or an explicit declaration in the document itself. If you are guessing it is because someone failed to properly store or transmit the document.
Both UTF-8 or UTF-16 are supported, yes, but that doesn't solve the problem because XML parsers have to deal with other encodings. A document that initially looks like UTF-8 could be almost any of literally hundreds of encodings including all the common ISO 8859 encodings. Which is why XML processing/parsing code has to go through multiple phases: a "try to determine the encoding" phase (using heuristics like those described in https://www.w3.org/TR/REC-xml/#sec-guessing) and then switch to a "parsing" phase after rewinding to the start of the document.
I did some work for a bank once which were in the process of moving to using XML as the universal messaging format (message bus architecture) and this wasn't some theoretical issue - it was a genuine pain as the message sources and sinks included a bunch of machines with different native encodings including a bunch of IBM machines (EBCDIC), old Windows machines, proprietary Unices like HPUX, along with Linux, etc.
This is a well known problem with XML.
Re: Do you hate XML? (2010)
#89XML is unfairly maligned. Yes, people bought into it too much 26 years ago, but then you would too if you had to maintain someone else's massive packed struct dumped into a file and documented in a poorly-maintained word document --- or worse, a brace of dumb IETF RFCs that contradict eachother. I am glad that younger generations are looking at it with fresh eyes. XML is a useful format; it has its place in your tool…
Anyone else encountering something that uses XML, they'll sort it into the realm of boomer stuff that you sic Claude on and not care about how it works, like Haskell or Angular.
Re: Do you hate XML? (2010)
#90Earlier quoted context omitted.
Again we come back to it being a markup language. In markup, it's usually pretty clear what is data and metadata: hello world and not bold hello world because you don't want the word "bold" to literally appear in the document. In structured data, the distinction is redundant.
Not always. For example, XML itself doesn't have types, so maybe you need to use attributes to store the data type (e.g. what if you need to do to lossless JSON XML conversion).