[WorldMaker]

> When I do need to parse XML, there was a library I could use, although I will admit that needing xpath was a bit annoying.

It sounds a bit like someone paved a garden path for you by that point. One of the reasons for the "enormous tool stack" wasn't just depth of tools needed ("tool X feeds tool Y which needs tool Z to process namespace A, but tool B to process namespace C, …"), but also the breadth. I recall there were at least six types of parsers to choose from with all sorts of trade-offs in memory utilization, speed, programming API: a complicated spectrum from forward-only parsers that read a node at a time very quickly but had the memory of a goldfish through to HTML DOM-like parsers that would slowly read an entire XML document all at once and take up a huge amount of memory for their XML DOM but you could query through the DOM beautifully and succinctly. (ETA: Plus or minus if you needed XSD validation at parsing time, and if you wanted the type hints from XSD to build type-safe DOMs, etc.)

A lot of XML history was standards proliferation in the xkcd 927 way: https://xkcd.com/927/

XPath tried to unify a lot of mini-DSLs defined for different DOM-style XML parsers.

XSLT tried to unify a bunch of XML transformation/ETL DSLs.

The things XPath and XSLT were designed to replace lingered for a while after those standards were accepted.

Eventually quite a few garden paths were paved from best practices and accepted "best recommended" standards and greenfield projects start to look easy and a simple number of well-coordinated tools. But do enough legacy Enterprise work and you can find all sorts of wild, brownfield gardens full of multiple competing XML parsers using all sorts of slightly different navigation and transformation tools.