3 ms·

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

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.
- mcswell 1y ago
  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.
  - jerf 1y ago
    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.
- mcswell 1y ago
  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 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 https://arxiv.org/pdf/1912.10817v1 (warning: poorly translated from the Russian original, and dated).

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.

mcswell 1y ago
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.
- jerf 1y ago
  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.
mcswell 1y ago
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 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 https://arxiv.org/pdf/1912.10817v1 (warning: poorly translated from the Russian original, and dated).