Other than looking ugly and being a pain to type does xml actually suck?

Is there an agreement on whether it’s

  <author name="pete" />

or

  <author>
    <name>pete</name>
  </author>

yet?

Yes there is. Markup languages are for representing rich text. Anything that gets rendered to the user is content and anything that's metadata (data about how to render) but not rendered as such goes into attributes. If there is no concept of "rendering to the user" in your app/data, then markup isn't the right choice for representing your data. You're blaming markup languages for not being designed to represent arbitrary data structures when you should be blaming yourself for misusing and misunderstanding markup. Though by skimming through this thread, XML appears to still do much better than YAML. And it's true that in the 00's, XML was improperly used and advocated as universal data format.

That is a reasonable approach - thanks.

Attributes are XML’s foot-gun.

Particularly annoying is that there's no way to do lists with attributes. Looks good:

  <user name="alice" group="wheel" />

Oh no:

  <user name="alice" groups="wheel admin sudoers" />

Or is it one of:

  <user name="alice" groups="wheel,admin,sudoers" />
  <user name="alice" groups="wheel:admin:sudoers" />
  <user name="alice" groups="wheel;admin;sudoers" />

Or give up and use elements:

  <user name="alice">
    <group>wheel</group>
    <group>admin</group>
    <group>sudoers</group>
  </user>

Hold on, should there be a container?

  <user name="alice">
    <groups>
      <group>wheel</group>
      <group>admin</group>
      <group>sudoers</group>
    </groups>
  </user>

XML really needs either richer attributes, or no attributes.

Replace with "Element" with "Class" and "Attribute" with "Property" in your examples.

It's your job to decide how the data should be structured, in any language.

I would do the following :

  <user name="alice">
    <groups>
      <group uid="wheel"/>
      <group uid="admin"/>
      <group uid="sudoers"/>
    </groups>
  </user>

Attributes are XML’s foot-gun.

I disagree. Back in the day we used attributes for everything that was key value and inner tags for anything with structure. We also formatted for clarity:

    <lunch
      env="outside"
      food="sandwiches"
      drink="cola"
    />

Compared with what we used to do, I look at attribute-less maven pom.xml with horror.

The decision of when and how to use attributes is the thing that is most often done wrong or clumsily in an XML file. That is my point.

What if it's to be used by french speaking software/people ?

    <lunch
      env="outside"
      envfr="dehors"
      food="sandwiches"
      foodfr="sandwichs"
      drink="cola"
    />

Or

    <lunch
      env="outside"
      food="sandwiches"
      drink="cola">
          <label type="env" language="fr">Dehors</label>
          <label type="env" language="de">Außenseite</label>
          <label type="env" language="en">Outside</label>
    </lunch>

Quite curious about it.

I guess this way:

  <lunch
    env="outside"
    food="sandwiches"
    drink="cola">
    <label xml:lang="fr">Dehors</label>
    <label xml:lang="de">Draußen</label>
    <label xml:lang="en">Outside</label>
  </lunch>

says[0]the w3.

[0]https://www.w3.org/TR/REC-xml/#sec-lang-tag

I see, thanks. (I also see you corrected my broken German ^^).

Putting l10n/i18n data inline is generally not a pleasant experience, and this problem persists regardless of what serialization format you are using. Either have separate data files per-locale that are merged with the defaults or store the localized strings in a central location (ala your usual gettext setup).

namespaces are absolutely a bear and always unpleasant to work with. The libraries to use xml are equally frustrating when you’re doing complicated things, unless you want to make a class for every single type of detail that this xml document wants - then it’s fine, but some of us don’t want to do that, or inherited a project that didn’t do that.

XPath is a struggle with namespaces, as well. It’s ... trying.

How is that relevant for config files though? If you implement an app and want to use a config file, you don't have to use namespaces. I agree that namespaces are no fun, so I don't use them for my config files.

Namespaces are great when used wisely: they allow for embedding unrelated XML fragments in your document and your application will not see them. Or versioning your XML in namespaces. XPath and namespaces are trivial but it depends on the library you use on how to setup the namespace resolving. My pet peeve about namespaces: people that use HTTP URLs for their declaration and expecting them to be resolved for some reason. The other one being people that see a namespace prefix and think that that is the actual namespace.

Depends on the XML. When you start mixing in namespaces (like trying to parse Maven pom.xml files in Python), it quickly becomes a mess.

Namespaces are horrible in Python because the Python XML libraries are deficient. They're generally fine in e.g. Java. (Unless you're trying to represent QName typed data, but that's very niche.)

I used Python as an example, but handling namespaces in most languages besides Java (and even arguably in Java depending on your point of view) is rather painful.

Any time the semantics represented by the XML is non-trivial, the schema design is likely to be obtuse and/or broken, even when done by smart people. XML is just hard to get right, and hard to evolve gracefully.

When you add verbosity on top of that, working with XML over the long haul is an utter pain.

I'd say the same about JSON!

Numbers over 2^52. Unicode. Terminator vs. Separator. Weak type system no DTD. No Xpath equivalent. No namespaces.

Date representations. No comments. Behavior when multiple instances of the same key occur.