> The complexity about XML comes from the many additional languages and tools built on top of it.

It's not just that, is it? There are also attributes versus child elements, dealing with white space including the xml:space attribute, namespaces, schemas, integration of external document fragments with xinclude:include or &extern;. Each of these is a huge can of worms in its own right. There are probably more that I'm not even aware of right now.

A few years ago, I wrote a fully functional parser for JSON that is easy to verify for correctness and that isn't just lying around somewhere as a toy, but is actually used (by me) in various projects time and again. Overall, building this parser was almost trivial. With XML, I'm not even sure I would be able to write a correct and complete parser.

But I agree with you that XML-based languages and XML tools make things even worse. I had to work with XML a lot over ten years ago. I still get annoyed when I think about XSLT, or dealing with schemas, or the challenge of finding usable tools that are reasonably compliant with standards.

You can only have a positive view of XML when you think of something like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <booklist>
      <book>
        <title>Example Book</title>
        <author>Max Mustermann</author>
        <year>2025</year>
      </book>
      <book>
        <title>Second Book</title>
        <author>Erika Musterfrau</author>
        <year>2026</year>
      </book>
    </booklist>

And at that level, I have (almost) no problem with XML. But as soon as things get more demanding and you really take the various aspects of XML's value proposition seriously, you enter a world of pain and despair. At least, that's how it was for me back then. Maybe I would see things differently today, but I'm not really interested in finding out.

First, you're describing the parsing side, while the message I was replying to claimed that it can't be written by hand.

Anyhow, schemas, XInclude and even namespaces are what I was referring to as additional languages of tools.

In your application you use them if you want, they're not really part of XML.

Of course even a parser for plain XML is a lot more complex than one for JSON, but people usually use libraries for that...

In any case, in your application nothing prevents you from using a dumbed-down version of XML, without entities, white space handling, and even only looking at elements and attributes; there were some applications that did that.

That already gives you a format that's easier to read and write manually than json.

I had more to say about "attributes versus child elements", but it's taking me too much time, I'll probably do that tomorrow.

I think I understand your point. I only brought parsing into play to illustrate that XML is complicated, not because it's my general focus. I wouldn't classify namespaces, etc. as additional languages and tools, but that's beside the point.

> in your application nothing prevents you from using a dumbed-down version of XML

That's right. And if XML were exactly that, then there wouldn't be so many people frustrated with it. Unfortunately, in a professional work context, you don't always have control over whether it stays within this manageable subset. Sometimes the less pleasant aspects simply come into play, and then you have to deal with the whole complicated mess.