Basically, they that by "extensible" they both wanted to support custom document markup languages/structures, but also the ability to extend those documents without needing to coordinate naming, etc.

But they messed it up by defining namespaces as an add-on to the core XML spec, rather than part of the spec itself. They also made 1-2 important errors in the definition of that add-on.

This led to XML tools being modal, having to support an interpretation of a document treating "xmlns" as a regular attribute and one where it was a namespace that influenced the interpretation of all the attributes/elements.

This push of complexity onto the people building schemas and using tools grew as there were two camps - one which wanted XML to be about generic tools that work on all XML data (similar to JSON today) and one where you used XML to define a specific document format for consumption by format-specific tools.

Various specifications were led by the generic tooling camp or document centric camp. As a result, XML eventually wound up being a poor fit for both.

An example of where this is an issue is using version as a name space ie tags with the form “<v2:customer>” and apply xslt on “<customer>”. Since they’re strings, they don’t match. The standard xslt solution is to strip the namespace from offending elements. Or change all your xslt. I learned this in an app with a few 100k lines of xslt.

The big thing we missed was better tools from the get-go, specially xml-aware text editors. That’s why the editors of the XML specification wanted to make things a bit easier for people doing things like writing XML with a plain text editor, or line-oriented processing using Perl. I think the amount of grief we are stuck with because of those time-limited needs is not worth it, thus the word “mistake” in the beginning of this post.

In hindsight, if anyone asked me how to add namespace support for XML, I would have required them all to be declared at the root of the document, in the XML declaration:

    <?xml version="1.0" standalone="yes"
          xmlns="https://docbook.org/ns/docbook"
          xmlns:m="http://fake-w3.org/2001/Math/not-the-real-MathML"?>
    <book>
        ...
        <equation>
            <title>MathML example</title>
            <m:math mode="display">
                <m:row>
                    <m:underover>
                        <m:o>∑</m:o>
                        <m:row>
                            <m:i>x</m:i>
                            <m:o>=</m:o>
                            <m:i>a</m:i>
                        </m:row>
                        <m:row>
                            <m:i>b</m:i>
                        </m:row>
                    </m:underover>
                    <m:sqrt>
                        <m:i>x</m:i>
                    </m:sqrt>
                </m:row>
            </m:math>
        </equation>
    </book>

I guess someone else mentioned this or a very similar idea at the time, and it was discarded to support plain text copy-and-paste by having the xmlns attribute in the element being copy-and-pasted. I don’t claim I would have done a better job, but I wish for a new version of XML that learns from these two and a half decades of use.

(We use schemas for all of our XML, because that way we can generate strongly-typed objects from them.)

Isn't that where the problems start, I'm willing to bet 99% of XML documents don't have more than one schema. We have ended up with a ton of complexity to support a minority of use cases. It's no wonder people embraced JSON.

One very common case where there are multiple schemas is SAML. SAML protocol responses have their own schema, SAML assertions have their own schema, assertions usually define their type with different schema (XML schema instance) & XML signatures have their own schema. https://www.samltool.com/generic_sso_res.php for example

The way JSON just kindof waltzed along and took over, despite the obvious drawbacks of it being schema-less, is really interesting.