There exists a peculiar amnesia in software engineering regarding XML. Mention it in most circles and you will receive knowing smiles, dismissive waves, the sort of patronizing acknowledgment reserved for technologies deemed passé. “Oh, XML,” they say, as if the very syllables carry the weight of obsolescence. “We use JSON now. Much cleaner.”
IMHO one of the fundamental problems with XML for data serialization is illustrated in the article:
The same data can be portrayed in two different ways. Whenever you serialize or deserialize data, you need to decide whether to read/write values from/to child nodes or attributes.
That’s because XML is a markup language. It’s great for typing up documents, e.g. to describe a user interface. It was not designed for taking programmatic data and serializing that out.
This is your confusion, not an issue with XML.
Attributes tend to be “metadata”. You ever write HTML? It’s not confusing.
In HTML, which things are attributes and which things are tags are part of the spec. With XML that is being used for something arbitrary, someone is making the choice every time. They might have a different opinion than you do, or even the same opinion, but make different judgments on occasion. In JSON, there are fewer choices, so fewer chances for people to be surprised by other people’s choices.
I mean, yeah. But people don’t just do things randomly. Most people put data in the body and metadata in attributes just like html.
Having to make a decision isn’t my primary issue here (even though it can also be problematic, when you need to serialize domain-specific data for which you’re no expert). My issue is rather in that you have to write this decision down, so that it can be used for deserializing again. This just makes XML serialization code significantly more complex than JSON serialization code. Both in terms of the code becoming harder to understand, but also just lines of code needed.
I’ve somewhat come to expect less than a handful lines of code for serializing an object from memory into a file. If you do that with XML, it will just slap everything into child nodes, which may be fine, but might also not be.
This is, without a doubt, the stupidest argument against XML I’ve ever heard. Nobody has trouble with using attributes vs. tag bodies. Nobody. There are much more credible complaints to be made about parsing performance, memory overhead, extra size, complexity when using things like namespaces, etc.
No - it is fine to just use tag bodies. You don’t need to ever use attributes if you don’t want to. You’ve never actually used XML have you?
https://www.baeldung.com/jackson-xml-serialization-and-deserialization
Okay, dude, glad to have talked.
JSON also has arrays. In XML the practice to approximate arrays is to put the index as an attribute. It’s incredibly gross.
I don’t think I’ve seen that much if ever.
Typically, XML repeats tag names. Repeating keys are not possible in JSON, but are possible in XML.
<items> <item></item> <item></item> <item></item> </items>That’s correct, but the order of tags in XML is not meaningful, and if you parse then write that, it can change order according to the spec. Hence, what you put would be something like the following if it was intended to represent an array.
<items> <item index="1"></item> <item index="2"></item> <item index="3"></item> </items>https://www.w3.org/TR/2004/REC-xml-infoset-20040204/
Does this not cover it?
Do you mean if you were to follow XML standard but not XML information set standard?
Information set isn’t a description of XML documents, but a description of what you have that you can write to XML, or what you’d get when you parse XML.
This is the key part from the document you linked
This is also a great example of the complexity of the XML specifications. Most people do not fully understand them, which is a negative aspect for a tool.
As an aside, you can have an enforced order in XML, but you have to also use XSD so you can specify xsd:sequence, which adds complexity and precludes ordered arrays in arbitrary documents.
If the XML parser parses into an ordered representation (the XML information set), isn’t it then the deserializer’s choice how they map that to the programming language/type system they are deserializing to? So in a system with ordered arrays it would likely map to those?
If XML can be written in an ordered way, and the parsed XML information set has ordered children for those, I still don’t see where order gets lost or is impossible [to guarantee] in XML.
You are correct that it is the deserializer’s choice. You are incorrect when you imply that it is a good idea to rely on behavior that isn’t enforced in the spec. A lot of people have been surprised when that assumption turns out to be wrong.
It can be used as alternatives. In MSBuild you can use attributes and sub elements interchangeably. Which, if you’re writing it, gives you a choice of preference. I typically prefer attributes for conciseness (vertical density), but switch to subelements once the length/number becomes a (significant) downside.
Of course that’s more of a human writing view. Your point about ambiguity in de-/serialization still stands at least until the interface defines expectation or behavior as a general mechanism one way or the other, or with specific schema.
XML is not great for user interfaces at all.
Eh, I don’t think it’s the be-all and end-all of describing user interfaces, but it deals well with the deep nesting that UIs generally have, and the attributes allow throwing in metadata for certain elements, which is also something you frequently need in UIs.
At the very least, JSON, YAML, INI and TOML would be a lot worse.
Well, from my experience working with android xml guis is soul crushing. While QML is much more pleasant, and it is kinda like json, but not quite.
Yeah, fair enough. I was thinking in terms of the more general-purpose text formats. I have heard good things about QML, too…