4 ms·

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.

by diulin 1y ago

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)

sbennettmcleish 1y ago
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).
jerf 1y ago
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 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.
- froh42 1y ago
  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.
- mcswell 1y ago
  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.
  - jerf 1y ago
    "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.
    - 1y ago
gomodon 1y ago
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.
ssdspoimdsjvv 1y ago
There's a working group dedicated to breathing new life into the standard: https://qt4cg.org/specifications/xslt-40/Overview.html https://qt4cg.org/specifications/xslt-40/Overview.html Last updated just under a week ago!

by diulin 1y ago

sbennettmcleish 1y ago

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).

jerf 1y ago

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 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.

froh42 1y ago
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.
mcswell 1y ago
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.
- jerf 1y ago
  "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.
  - 1y ago

gomodon 1y ago

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.

ssdspoimdsjvv 1y ago

There's a working group dedicated to breathing new life into the standard: https://qt4cg.org/specifications/xslt-40/Overview.html https://qt4cg.org/specifications/xslt-40/Overview.html Last updated just under a week ago!