XML/XSLT/XPath are great, but XSLT ecosystem has been effectively "frozen" for over a decade in terms of innovation and tooling. The last major step was XSLT 3.0 (2017), which introduced streaming and function integration. However, in practice, no new engines or radically different approaches have emerged since then.
And there is only one free XSLT 3.0 processor available, SAXON-HE (it lacks schema-aware & streaming though)
Even worse, in practice you still often only get to use XSLT 1 and XPath 1, because that's what the common Open Source libraries (i.e. libxml/libxslt and Xalan) typically used to embed XSLT into Software support. (The existence of EXSLT should better be forgotten). For anything else, esp. dedicated standalone XSLT development, there is basically only saxon. I wish, there was better Open Source support for XSLT/XPath 2+ but i don't think it's likely to happen.
I'd say damn near 20yrs. I used it quite extensively about 10yrs ago and it was an odd one then, but was very useful for the purpose we had (semantic validation of XML payloads).
XSLT is a bad programming language wrapped around XPath. I'd rather take any existing general purpose programming language, add an XPath library to it, and write anything I'd do in XSLT in a programming language where I don't have to wait until version 3.0 for, well, all this stuff: https://www.w3.org/TR/xslt-30/#whats-new-in-xslt3
And a lot of that "badness" is precisely that XSLT is a very closed, scarcity-minded language where basic library and language features have to be routed through a standards committee (you think it's hard to get a new function into Python's or Go's standard library?), when all you really need is an XPath library and any abundance-mindset language you can pick up, where if you need something like "regular expression" support you can just go get a library. Or literally anything else you may need to process an XML document, which is possibly anything. Which is why a general-purpose language is a good fit.
That "What's New In XSLT 3.0" is lunatic nonsense if you view it through the lens of being a programming language. What programming language gets associative arrays after 18 years? And another 8 years after that you still can't really count on that being available?
Programming languages tend to have either success feed success, or failure feed failure. Once one of those cascades start it's very difficult to escape from them. XSLT is pretty firmly in the latter camp, probably kept alive only by the fact it's a standard and that still matters to some people. It's frozen because effectively nobody cares, because it's frozen, because nobody cares.
I definitely recommend putting XPath in your toolbelt if you have to deal with XML at all though.
Years ago, I was maintaining a huge XML->XML transformation in XSLT. The input format was the XML based config file of the system, that was created by the configuration tool. Output was a XML that has the same information in a way that is optimized for the system to read in efficiently. (Changing order of things, introducting redundancy by replicating similar information for different parts of the system, etc.)
(It was a Building Information System, Fire Alarms, Access, Lots of business rules stored in XML)
While the XML was easier to transform in XSLT than in the native C++, and yes, XSLT was probably the right tool at that time I developed a deep hatred for XSLT at that time. It felt like a functional language that had just all the important parts removed.
Yes, pattern matching is a good thing, but hey - I can do pattern matching for rules in any decent language. It was just the amount of existing code that prevented me from porting it to another language.
(And I remember a few ugly hacks, where I exposed "programming language" stuff from C# - which we also used - to the XSLT processor)
However, with all the XSLT ugliness: XPath is amazing! I love that.
I was wondering whether I was the only person to think XSLT was a poor tool, although for different reasons. I had to work with XSLT for several years, and it felt like the worst programming language I had ever seen. For me, the use of code written in XML to process XML felt absurd, and debugging felt next to impossible. I thought it would be nice if someone would create a library in some other programming language (maybe Prolog) that would do the same thing. If it had to first had to "compile" stuff into XSLT, so be it, but programming in XML was so verbose that I had trouble keeping track of my program's structure.
"I thought it would be nice if someone would create a library in some other programming language"
It's just XPath. Grab your favorite programming language, grab XPath, start transforming and outputting. You still probably ought to learn XPath, but unlike XSLT as a whole, learning XPath rather quickly starts paying off.
BTW, I decided I'd see if there was an XPath library for Prolog (once my favorite programming language, and with some conceptual/ algorithmic similarity to XSLT, I think, although XSLT has nothing like Prolog's backtracking). Turns out there is (at least) one: https://www.swi-prolog.org/pldoc/man?predicate=xpath%2f3.
There's a comparison of Prolog and XSLT v1 here: https://arxiv.org/pdf/1912.10817v1 (warning: poorly translated from the Russian original, and dated).
I did know XPath, although I found out the other day that I'd forgotten a lot about it. I was programming in Python using the xml.dom library, which afaict doesn't use XPath at all--I wish it did, I had a very deeply nested set of if-else and for statements to get to something that would have been a single XPath. There's another Python XML library, xml.etree, which provides some ("limited") XPath support, but I had already written most of the code I needed using the dom library when I ran into this.
I will say that for all I'm singing the praises of XPath, the online tutorials and documentation are atrocious. Possibly the worst ratio of quality to library power I've seen. I recently came back to it after a couple of years and couldn't hardly do anything either because I couldn't even reconstruct my previous understanding off of the documentation, but then I consulted my own notes and docs about it and it all came back quickly.
There are two problems. First, everyone is obsessed with trying to label it "declarative" when it is waaaaay better understood as a library for driving around a multicursor imperatively. Call it declarative if you like but I've had way more success driving it effectively imperatively.
Second, each XPath clause has three parts: The "axes", which is the "direction" you want to drive the cursor, the "node selection" which selects which nodes you are talking about (usually the tag name), and then optional filters in [], which can then itself recurse in some ways into further XPath specifications, as well as using some functions and predicates to filter. Fortunately for your convenience, there's a default axis, selecting nodes by tag name is easy, and the filters are indeed optional. Unfortunately for your understanding, there's other defaults and shortcuts and all the "tutorials" and "cheat sheets" and all that jazz teach only the shortcuts, but if you learn only the shortcuts the whole language feels random and very difficult to understand. You really need to learn the full version of the selector clause first, practice by writing it out fully a few times, and then starting to use the shortcuts.
(You can even see the "node selection" as just a type of filter that looks at the tag name most of the time, in which case there are two parts. But it's really confusing when tutorials don't distinguish very well between those two things and mangle it all up into one undifferentiated ball.)
It's not that hard if you are taught it correctly, but I have yet to find something that teaches it correctly online.
