>If you're using Schemas for your XML then you need namespaces in case you've got two different elements from different schemas that have the same name.

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.

These days I wouldn't be surprised if fairly large portion of XML documents that are still in use/produced did have multiple schemas. Most of the simple use cases have already moved to JSON or similar formats.

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

Even worse than that: 99% of all schemas mandate exclusivity (or at least exclusive subtrees, it's been a while). The dominant schema techniques rule out markup unless you explicitly bends over for it while jumping through hoops.

So many schemas are all or nearly all optional elements, so the point about typing rarely works oh in practice.

yes exactly, they tried to make xml V1 cover every eventuality for all time and created a fussy mess

Yes I know its got a use and it makes sense when stated simply but when you get into the details everything about XML is so excessive because they tried to cover everything, so then you have namespaces and default namespaces and target namespaces and because the schemas are also defined in XML you get DTDs and XSDs and you end up trying to describe arbitrary contraints using really fiddly tags.

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

I would argue the file format had nothing to do with JSON being popular: it is much much easier to generate and access an object that is essentially a native serialization format, so even if you never ever see the XML (and thereby never have to deal with the namespace rules) JSON was going to win over XML for a developer in JavaScript, certainly.. and then the format is also trivially mappable to almost any other language as JavaScript is so devoid of types.

At this point, if I don't need efficiency I just use JSON as my wire format. Need to integrate a C++ card game engine with emscripten? I expose 2 functions, one that dumps all as JSON and one that accepts legal moves. The JSON syntax is pretty irrelevant except for light debugging - however, the easy mapping without fussing over many alternate representations is quite relevant