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

  • aivoton@sopuli.xyz
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    5 hours ago

    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.

    • Ephera@lemmy.ml
      link
      fedilink
      English
      arrow-up
      7
      ·
      4 hours ago

      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.

      • aivoton@sopuli.xyz
        link
        fedilink
        arrow-up
        1
        ·
        2 hours ago

        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.