3 ms·

It's such a shame that XSLT has such a poor image - v1.0 was troublesome for sure, but the modern language is remarkably flexible, expressive and elegant, as lo

It's such a shame that XSLT has such a poor image - v1.0 was troublesome for sure, but the modern language is remarkably flexible, expressive and elegant, as long as you leave your procedural baggage at the door. It's not without its wobbly bits, but show me a language that isn't.

tangue 9y ago
SOAP, RDF and the semantic web clique, and other monstruosities of the 2000s gave XML a bad name but XSLT is nice. Indeed it would have been a nicer solution than responsive css to tackle the challenges of mobile devices.
- gavinpc 9y ago
  Amen. And while we're at it, let's throw some of the credit to XPath. Wouldn't you like concise, declarative traversal for your data structures? (Yeah, I'm sure somebody's already built it.) I don't think I agree about responsive css, but that's another discussion.
  - err4nt 9y ago
    I experiment with using XPath selectors to apply styling :D Can reach many things CSS selectors arent designed to reach!
- tannhaeuser 9y ago
  I've done quite extensive XSLT development and like it for particular tasks, but I think XSLT's weak points are 1. It's Turing-complete, which means you can just use any other language for XML manipulation as well such as JavaScript (has DOM language bindings) or Prolog (rule/pattern based like XSLT) or maybe LISP (like DSSSL was). The benefit is that using a mainstream language gives you better mindshare and infrastructure such as APIs for DB access, IDE support for testing, etc. which I found inevitably necessary in every large XSLT project 2. XSLT 2 and 3 only has a single implementation (Saxon) by the same author as the XSLT spec itself - not my idea of a standard (and, in fact, not meeting W3C's criteria of at least two interoperable implementations). XSLT works well if you need lots of literal XML content to be produced to the output, but will get verbose, degenerative, and awkward (priority rules) for highly dynamic content.
fnord123 9y ago
I used XSLT on a project. I came from a functional mindset. XSLT is terrible and deserves its poor image.
mikekchar 9y ago
I should probably admit that I really like XSLT (perhaps I'm insane too), but it was really unsuited to the task we were using it for. I've since done quite a bit of XSLT and it's definitely the main tool I'd use if I wanted to screen scrape some HTML, for instance. But can you imagine someone saying "We want you to draw paths between points and they can't cross. And we want you to do it in XSLT"? I mean, you can do it... but... "not fun" doesn't begin to describe the pain.
mikegerwitz 9y ago
I ended up writing a full compiler stack in XSLT for declarative, XML-based DSLs[0][1] and a few targets (mainly JavaScript and HTML). It didn't start out as that, but having already written basic HTML/JS generation from a simple DSL, it evolved from there. It was originally written in XSLT 1.0 so that it could generate in the web browser, which had some serious limitations and was incredibly verbose. XSLT 2 is much less verbose, but obviously XML is verbose in general. If I had to do it over, I'd use Lisp, but the functional and template-based style of XSLT made for very natural syntax-directed translation for the compilers. I still have the cruft of old XSLT 1 code (which was written when I was also _learning_ XSLT), but all things considered, it's not all that bad. Most of the pain points are the patchwork evolution of the project; done from scratch in XSLT, it'd be much more elegant. And, like Lisp, XSLT can parse itself as data (sans xpath). That allowed me to use a semi-literate style (generate literate documentation from the sources), for example. [0]: https://github.com/lovullo/tame https://github.com/lovullo/tame [1]: https://github.com/lovullo/liza-proguic/tree/master/src https://github.com/lovullo/liza-proguic/tree/master/src [2]: https://github.com/lovullo/literate-xsl https://github.com/lovullo/literate-xsl with example output https://mikegerwitz.com/hoxsl/manual/ https://mikegerwitz.com/hoxsl/manual/

tangue 9y ago

SOAP, RDF and the semantic web clique, and other monstruosities of the 2000s gave XML a bad name but XSLT is nice. Indeed it would have been a nicer solution than responsive css to tackle the challenges of mobile devices.

gavinpc 9y ago
Amen. And while we're at it, let's throw some of the credit to XPath. Wouldn't you like concise, declarative traversal for your data structures? (Yeah, I'm sure somebody's already built it.) I don't think I agree about responsive css, but that's another discussion.
- err4nt 9y ago
  I experiment with using XPath selectors to apply styling :D Can reach many things CSS selectors arent designed to reach!
tannhaeuser 9y ago
I've done quite extensive XSLT development and like it for particular tasks, but I think XSLT's weak points are 1. It's Turing-complete, which means you can just use any other language for XML manipulation as well such as JavaScript (has DOM language bindings) or Prolog (rule/pattern based like XSLT) or maybe LISP (like DSSSL was). The benefit is that using a mainstream language gives you better mindshare and infrastructure such as APIs for DB access, IDE support for testing, etc. which I found inevitably necessary in every large XSLT project 2. XSLT 2 and 3 only has a single implementation (Saxon) by the same author as the XSLT spec itself - not my idea of a standard (and, in fact, not meeting W3C's criteria of at least two interoperable implementations). XSLT works well if you need lots of literal XML content to be produced to the output, but will get verbose, degenerative, and awkward (priority rules) for highly dynamic content.

fnord123 9y ago

I used XSLT on a project. I came from a functional mindset. XSLT is terrible and deserves its poor image.

mikekchar 9y ago

I should probably admit that I really like XSLT (perhaps I'm insane too), but it was really unsuited to the task we were using it for. I've since done quite a bit of XSLT and it's definitely the main tool I'd use if I wanted to screen scrape some HTML, for instance. But can you imagine someone saying "We want you to draw paths between points and they can't cross. And we want you to do it in XSLT"? I mean, you can do it... but... "not fun" doesn't begin to describe the pain.

mikegerwitz 9y ago

I ended up writing a full compiler stack in XSLT for declarative, XML-based DSLs[0][1] and a few targets (mainly JavaScript and HTML). It didn't start out as that, but having already written basic HTML/JS generation from a simple DSL, it evolved from there. It was originally written in XSLT 1.0 so that it could generate in the web browser, which had some serious limitations and was incredibly verbose. XSLT 2 is much less verbose, but obviously XML is verbose in general. If I had to do it over, I'd use Lisp, but the functional and template-based style of XSLT made for very natural syntax-directed translation for the compilers. I still have the cruft of old XSLT 1 code (which was written when I was also _learning_ XSLT), but all things considered, it's not all that bad. Most of the pain points are the patchwork evolution of the project; done from scratch in XSLT, it'd be much more elegant. And, like Lisp, XSLT can parse itself as data (sans xpath). That allowed me to use a semi-literate style (generate literate documentation from the sources), for example. [0]: https://github.com/lovullo/tame https://github.com/lovullo/tame [1]: https://github.com/lovullo/liza-proguic/tree/master/src https://github.com/lovullo/liza-proguic/tree/master/src [2]: https://github.com/lovullo/literate-xsl https://github.com/lovullo/literate-xsl with example output https://mikegerwitz.com/hoxsl/manual/ https://mikegerwitz.com/hoxsl/manual/