- markup (52)
- xml (7)
- xslt (21)
- atom (8)
- overlapping markup (2)
- schema (9)
- creole (4)
- xforms (1)
- pipelines (7)
- coding (2)
- dtll (1)
- genealogy (3)
- gtd (1)
- hardware (1)
- legislation (1)
- ontologies (2)
- unicode (1)
- web (24)
- google (3)
- rdf (6)
- rest (3)
- wikis (1)
- work (1)
- xpath (1)
- xquery (1)
- xtech2008 (3)
- life (26)
- children (5)
- equality (6)
- environment (4)
- gadgets (5)
- software (3)
- xlinq (2)
- conferences (7)
- xtech (6)
- blog (7)
- drupal (3)
Re: Big XSLT applications just got easier to manage
As you probably know, there have been many attempts over the years to make XSLT less verbose, the most recent I saw being
XQuerySam Wilmott’s RXSLT, presented at Extreme Markup Languages last year. XSLScript seems to have disappeared, but NiceXSL is still around. These attempts are largely, in my experience, suited for one particular person — their developer — and don’t get much use outside that rather small set.But the general approach is very useful, and something that all serious XSLT programmers should have in their toolkit: write an abstract, declarative description of what you want the transformation to do; write a program (perhaps in XSLT) to transform that into XSLT; and run. Basically, it’s writing a compiler from your own notation into XSLT: from one extremely high-level programming language into another very high-level programming language. I wouldn’t personally use the approach as a general XSLT replacement, but I have done it for specific processing, to counter the verbosity of having lots of very similar templates in a stylesheet.
There are downsides, of course, in particular difficulties with debugging, and it’s always a good idea to leave an “escape hatch” so that you can write in normal XSLT if your more abstract syntax doesn’t quite manage all the bells and whistles. The approach will get that much easier to use when XProc gets done, because there’ll be an easy way to string the compilation and the transformation together into a single command.
I’m sure that Dimitre will be very interested in what you’re up to, particularly as you’re using Haskell as your notation, and he would probably be in a better position to talk about the specifics.