59
The lost art of XML — mmagueta (marcosmagueta.com)
submitted 9 months ago by to c/programming@programming.dev
91 comments fedilink hide all child comments
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] 26 points 9 months ago (22 children)

IMHO one of the fundamental problems with XML for data serialization is illustrated in the article:

(person (name "Alice") (age 30))
[is serialized as]

<person>
  <name>Alice</name>
  <age>30</age>
</person>

Or with attributes:
<person name="Alice" age="30" />

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.

  • permalink
  • fedilink
  • source
  • hideshow 22 child comments
    •
  • [+] 8 points 9 months ago (6 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] [S] 5 points 9 months ago (5 children)

    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>
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [+] 10 points 9 months ago* (4 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 6 points 9 months ago* (3 children)

    https://www.w3.org/TR/2004/REC-xml-infoset-20040204/

    [children] An ordered list of child information items, in document order.

    Does this not cover it?

    Do you mean if you were to follow XML standard but not XML information set standard?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [+] 3 points 9 months ago (2 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 9 months ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
    load more comments (1 reply)
  • [–] 7 points 9 months ago (5 children)

    This is your confusion, not an issue with XML.

    Attributes tend to be "metadata". You ever write HTML? It's not confusing.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 3 points 9 months ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -1 points 9 months ago (1 child)

    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.

    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.

    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.

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 2 points 9 months ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 9 months ago* (3 children)

    The same data can be portrayed in two different ways.

    And that is issue why? The specification decided which one you use and what do you need. For some things you consider things as attributes and for some things they are child elements.

    JSON doesn't even have attributes.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 7 points 9 months ago (2 children)

    Alright, I haven't really looked into XML specifications so far. But I also have to say that needing a specification to consistently serialize and deserialize data isn't great either.

    And yes, JSON not having attributes is what I'm saying is a good thing, at least for most data serialization use-cases, since programming languages do not typically have such attributes on their data type fields either.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 9 months ago (1 child)

    I worded my answer a bit wrongly.

    In XML <person><name>Alice</name><age>30</age></person> is different from <person name="Alice" age="30" /> and they will never (de)serialize to each other. The original example by the articles author with the person is somewhat misguided.

    They do contain the same bits of data, but represent different things and when designing your dtd / xsd you have to decide when to use attributes and when to use child elements.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 7 points 9 months ago

    Ah, well, as far as XML is concerned, yeah, these are very different things, but that's where the problem stems from. In your programming language, you don't have two variants. You just have (person (name "Alice") (age 30)). But then, because XML makes a difference between metadata and data, you have to decide whether "name" and "age" are one or the other.

    And the point I wanted to make, which perhaps didn't come across as well, is that you have to write down that decision somewhere, so that when you deserialize in the future, you know whether to read these fields from attributes or from child nodes.
    And that just makes your XML serialization code so much more complex than it is for JSON, generally speaking. As in, I can slap down JSON serialization in 2 lines of code and it generally does what I expect, in Rust in this case.

    Granted, Rust kind of lends itself to being serialized as JSON, but well, I'm just not aware of languages that lend themselves to being serialized as XML. The language with the best XML support that I'm aware of, is Scala, where you can actually get XML literals into the language (these days with a library, but it used to be built-in until Scala 3, I believe): https://javadoc.io/doc/org.scala-lang.modules/scala-xml_2.13/latest/scala/xml/index.html
    But even in Scala, you don't use a case class for XML, which is what you normally use for data records in the language, but rather you would take the values out of your case class and stick them into such an XML literal. Or I guess, you would use e.g. the Jackson XML serializer from Java. And yeah, the attribute vs. child node divide is the main reason why this intermediate step is necessary. Meanwhile, JSON has comparatively little logic built into the language/libraries and it's still a lot easier to write out: https://docs.scala-lang.org/toolkit/json-serialize.html

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 9 months ago (3 children)

    XML is not great for user interfaces at all.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 9 months ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •