There is also the matter of implementation quality and robustness, and the future of XML as a supported technology. XML technology is over 20 years old, and ma

There is also the matter of implementation quality and robustness, and the future of XML as a supported technology. XML technology is over 20 years old, and mainstream support for it has been slowly declining. If you're writing in any language other than Java, you don't have any good choices if you want to use more than the basic SAX/DOM APIs, and all of the available libraries have significant drawbacks if you want to do anything more than the bare essentials. I can fully understand why projects want to drop their existing XML dependencies where possible, and shy away from picking up new ones. If you're writing a product using C or C++, then you've got few choices: Apache Xerces-C and Xalan-C for XML and XSLT/XPATH, respectively. Or libxml/libxslt. Neither of these is a good choice (for the record, I'm involved with both Apache projects on an ad-hoc basis). Or QtXml/QtXmlPatterns. There are others but they aren't worth writing about. The Apache projects had pretty comprehensive support for the earlier XML and XSLT/XPATH standards, and matched the Java implementations pretty closely. But with the waning interest in XML, and the huge amounts of technical debt involved, both projects have been in maintenance mode for the last decade. No one wants to break compatibility with significant rework. Then there's the GNOME-derived libxml/libxslt. A little more modern but C-only, and lacking most of the features provided by the Apache implementation. OK if a simple subset is sufficient, but otherwise not viable. The Qt libraries are good, but it's a very heavy dependency and is again a subset of the Apache functionality, and is XSLT2 only. When it comes to adding in XPATH 2.0, there just isn't the maintainer interest available, primarily because there's no corporate interest in taking any of these projects forward in any meaningful way. XML is no longer cool or interesting, and as such projects are not willing to spend time and money on maintaining these codebases. They are all, to varying degrees, in maintenance mode. I previously worked on a large project that for various reasons, including jumping on the bandwagon of the moment, heavily opted into using XML, XSLT and using as many obscure features as possible. Being Java based, it had access to jars for doing pretty much any XML processing it liked. If the core functionality provided by the JDK isn't enough, you've got Saxon and other implementations readily to hand. I had to port a subset of the functionality to C++, and the only possibilities were Xerces+Xalan. libxml/libxslt simply didn't have the featureset for all of the obscure XML processing features needed, or all the EXSLT functions. Needing to depend upon a pair of obsolete, essentially unmaintained and difficult to use libraries is why I ended up involved in their maintenance. I later added Qt support as an alternative, but at the expense of having to disable a huge amount of core functionality. I'd like nothing more than to dump the lot of them. It's also worth pointing out that the root of the problem here is the absurd complexity of all of the (many) XML standards and APIs. A fairly simple concept which has so much complex stuff layered upon and grafted onto it that it's not really much of a wonder that it's in such of a poor state. It should have been kept simple.