Comment by Aurornis

HTML was conceived as a language for marking up a document that was primarily text; XML took the tags and attributes from that and tried to turn it into a data serialization and exchange format. But it was never really well suited to that, and it's obvious from looking XML-RPC or SOAP payloads that there were fundamental gaps in the ability of XML to encode type and structure information inline:

    <?xml version="1.0"?>
    <methodCall>
        <methodName>math.add</methodName>
        <params>
            <param>
                <value><int>5</int></value>
            </param>
            <param>
                <value><int>7</int></value>
            </param>
        </params>
    </methodCall>

Compared to this, JSON had string and number types built in:

    {
        "jsonrpc": "2.0",
        "method": "math.add",
        "params": [5, 7],
        "id": 1
    }

I don't think this is the only factor, but I think XML had a lot of this kind of cognitive overhead built in, and that gave it a lot of friction when stacked up against JSON and later yaml... and when it came to communicating with a SPA, it was hard to compete with JS being able to natively eval the payload responses.

> developers used it and did not like it.

This makes sense.

However, there are two ways to address it:

1) Work towards a more advanced system that addresses the issues (for example, RDF/Turtle – expands XML namespaces to define classes and properties, represents graphs instead of being limited to trees unlike XML and JSON)

2) Throw it away and start from scratch. First, JSON. Then, JSON schema. Jq introduces a kind of "JSONPath". JSONL says hi to XML stream readers. JSONC because comments in config files are useful. And many more primitives that existed around XML were eventually reimplemented.

Note how the discussion around removing XSLT 1 support similarly has two ways forward: yank it out or support XSLT 3.

I lean towards Turtle replacing XML over JSON, and for XSLT 3 to replace XSLT 1 support in the browsers.

The simplest explanation is that attributes were a mistake. They add another layer to the structure and create confusion as to where data is best stored within it.

XML without attributes probably would have seen wide and ready adoption.

While i think a lot of xml was a bad idea, some of the issues are not instrinsically the fault of XML but some really poor design decisions by people making xml based languages.

They tended to be design by comittee messes that included every possible use case as an option.

Anyone who has ever had the misfortune of having to deal with SAML knows what i'm talking about. Its a billion line long specification, everyone only implements 10% of it, and its full of hidden gotchas that will screw up your security if you get them wrong. (Even worse, the underlying xml-signature spec is literally the worst way to do digital signatures possible. Its so bad you'd think someone was intentionally sabotaging it)

In theory this isn't xml's fault, but somehow XML seems to attract really bad spec designers.

Regarding containerization, XML wouldn’t just be a noun, but a verb (like in XSLT). You would define your remote procedures in XML.

Imagine if instead of the current Dockerfile format, we used XML, which was dynamically generated from lists of packages, and filtered and updates according to RSS feeds describing CSVs and package updates.

I’m not saying this is anything other than strange fantasy. And not a particularly nice fantasy either.

XML failed because it forced devs to spend tons of unproductive time on it

Part of the problem was it came in an era before we really understood programming, as a collective. We didn't even really know how to encapsulate objects properly, and you saw it in poor database schema designs, bizarre object inheritance patterns, poorly organised APIs, even the inconsistent method param orders in PHP. It was everywhere. Developers weren't good at laying out even POCOs.

And those bizarre designs went straight into XML, properties often in attributes, nodes that should have been attributes, over nesting, etc.

And we blamed XML for the mess where often it was just inexperience in software design as an industry that was the real cause. But XML had too much flexibility compared to the simplicity of the later JSON, meaning it helped cause the problem. JSON 'solved' the problem by being simpler.

But then the flip side was that it was too strict and starting one in code was a tedious pita where you had to specify a schema even though it didn't exist or even matter most of the time.