XML as a document markup language was neat imvho.

Like, I remember working with DocBook XML[0] and it was fine. And the idea of being able to use different namespaces in a document (think MathML and SVG in XHTML) was neat too.

The problems arose from the fact that it was adopted for everything where it largely didn't make much sense. So people came to hate it because e.g. "a functional language to transform XML into other formats" is neat, but "a functional language written in XML tags" is a terrible idea"[1].

Likewise, "define a configuration in XML" seems a good idea, but "a build system based on XML plus interpolation you're supposed to edit by hand" is not great[2].

So people threw away all of the baby XML with the bathwater, only to keep reinventing the same things over and over, e.g. SOAP+WSDL became a hodgepodge of badly documented REST APIs, swagger yaml definitions and json schemas, plus the actual ad-hoc encoding.

And I mean, it's not like SOAP+WSDL actually worked well either, it was always unreliable. And even the "mix up namespaces" idea didn't work out, cause clients never really parsed more than one thing at a time, so it was pointless (with notable small exceptions). XML-RPC[3] did work, but you still needed to have the application model somewhere else anyway.

Still, JSON has seen just as much abuse as a "serialization" format which ended up abused as configuration, schema definitions, rules language... It's the circle of life.

[0] https://docbook.org/

[1] https://developer.mozilla.org/en-US/docs/Web/XML/XSLT

[2] https://ant.apache.org/manual/using.html

[3] https://en.wikipedia.org/wiki/XML-RPC

I think XML fit well into the turn-of-the-millenium zeitgeist: GUIs would hide the verbosity; the proliferation of bespoke tags would map cleanly to OOP representations; middleware could manipulate and transform data generically, allowing anything to plug into anything else (even over the Internet!).

Whilst lots of impressive things were built, the overall dream was always just out of reach. Domain-specific tooling is expensive to produce and maintain, and often gives something that's not quite what we want (as an extreme example, think of (X)HTML generated by Dreamweaver or FrontPage); generic XML processors/editors don't offer much beyond avoiding syntax/nesting errors; so often it was simplest to interact directly with the markup, where the verbosity, namespacing, normalisation, etc. wouldn't be automated-away.

XML's tree model was also leaky: I've worked with many data formats which look like XML, but actually require various (bespoke!) amounts of preprocessing, templating, dereferencing, etc. which either don't fit the XML model (e.g. graphs or DAGs), or just avoid it (e.g. sprinkling custom grammar like `${foo.bar}` in their text, rather than XML elements like `<ref name="foo.bar" />`). Of course, it was hard to predict how those systems would interact with XML features like namespaces, comments, etc. which made generic processing/transforming middleware less plug-and-play. That, plus billion-laugh mitigation, etc. contributed to a downward spiral of quality, where software would not bother supporting the full generality of XML, and only allowed its own particular subset of functionality, written in one specific way that it expected. That made the processors/transformers even less useful; and so on until eventually we just had a bunch of bespoke, incompatible formats again. At which point, many just threw up their hands and switched to JSON, since at least that was simpler, less verbose and easier to parse... depending whether you support comments... and maybe trailing commas...; or better yet, just stick to YAML. Or TOML.....

(My favourite example: at an old job, I maintained an old server that sent orders from our ecommerce site to third party systems, using a standard "cXML" format. Another team built a replacement for it, I helped them by providing real example documents to test with, and eventually the switch was made. Shortly after, customers were receiving dozens of times what they ordered! It turned out that a third-party was including an XML declaration like `<?xml>` at the start of their response, which caused the new system to give a parse failure: it treated that as an error, assumed the order had failed, and retried; over and over again!)

>And I mean, it's not like SOAP+WSDL actually worked well either, it was always unreliable.

I don't think it ever worked. See this [0]. It's pretty crazy that people build one of the most complex and verbose data exchange formats in the world and then it turns out that duplicating the open and close tag and including the parameter name and type in the attributes bought you nothing, because implementations are treating your SOAP request as an array of strings.

[0] https://snook.ca/archives/other/soap_request_pa