|
In your call for comments, you asked, "Do you have any favorite ways to debug or understand XSLT sheets?" My favorite strategy is to reduce XSLT's complexity at its source.
To my mind, XSLT has two problems that work together to bog us down. First, XSLT lacks the expressiveness to handle elegantly many problems that are commonplace. Second, XSLT is essentially a programming language embedded within XML. While XML is great for expressing marked-up documents, it is makes a syntactically noisy and verbose carrier for a programming language.
The first problem forces us to write more XSLT than we ought to, and the second magnifies the bloating properties of that extra code. A nasty duo, they are.
Luckily for us, there are decent solutions to both of these problems. First, EXSLT (http://www.exslt.org/) is a community effort to extend XSLT with support for commonplace needs like string manipulation, date and time processing, and fragment-to-nodeset conversion. Most popular XSLT processing engines support EXSLT in one way or another, either via built-in support or via the use of EXSLT implementations written in vanilla XSLT. If you haven't used EXSLT, do check it out. It can save you a lot of code.
For the second problem, take a look at PXSL ("pixel") (http://community.moertel.com/pxsl/). It's an XML shorthand that was designed specifically for the purpose of representing data-centric documents and embedded programming languages like XSLT. (It even has built-in XSLT shortcuts.) It's simple, straightforward, and open source. For advanced users, it offers custom shortcuts and macros, but the streamlined syntax alone makes stylesheets much easier to work with. It does a good job at taking care of XSLT's second problem.
|
Previous Message
