Discover the Wonders of XSLT: XSLT Quirks
You've made it to Part 4 of this XSLT introduction at developer.com. Congratulations! You have learned how to create efficient style sheets to process your XML documents.
I trust that, as your experience with XSLT grows, you begin to appreciate how versatile the language is. As easy as it is to hack a style sheet quickly to reformat a document, it is equally easy to integrate style sheets in more serious production environments, such as processing orders in an e-commerce setup.
Truly, XSLT is a tool with many uses.
When I teach XSLT in seminars, the most frequent complaint is that XSLT is a verbose language. After a few exercises, students appreciate the power of the language but few like the syntax.
My answer is twofold:
- First, you may want to consider a good XSLT editor. Many students like XML Spy (www.altova.com). On the Eclipse platform, I recommend XML Buddy (www.xmlbuddy.com). Still, I do most of my coding with BBEdit (www.barebones.com) or Boxer (www.texteditors.com). Both offer syntax coloring.
- Keep practicing. The XSLT syntax has one distinct advantage: It makes it almost impossible for your style sheets to produce invalid XML documents. With time, you will come to appreciate this.
XSLT is a very specialized language with a distinct declarative flavor. The templates, introduced in Part 1, are a declarative set of rules to render and format XML elements.
The developer need not explicitly call the templates; instead, each template specifies (in its match attribute) to which element it applies and the XSLT processor automatically calls the relevant templates.
The declarative flavor is in sharp contrast with more generic languages (Java, C#, C++, Basic, or Pascal) where the developer has to call methods explicitly. In my experience, XSLT's declarative flavor is the source of some confusion.
Part 2 and Part 3 of this series introduced a more procedural flavor to XSLT with the for-each, if, and choose instructions. Some of my students jump on these instructions and never look back to declarative templates again... until they hit a wall.
To avoid problems, you should realize that there are two different coding styles in XSLT: the declarative flavor that uses templates and predicates, and the procedural flavor with loops and tests. XSLT, as a language, is biased towards the first and this bias should be reflected in your style sheets.
Specifically, you might be tempted to write the following code:
<xsl:template match="a:para"> <xsl:choose> <xsl:when test="@type='bold'"> <p><b><xsl:apply-templates/></b></p> </xsl:when> <xsl:otherwise> <p><xsl:apply-templates/></p> </xsl:otherwise> </xsl:choose> </xsl:template>
Don't. The preceding code uses one template and then a test. The more correct expression in XSLT is to use two templates, one for each condition, and let the processor select the more appropriate one:
<xsl:template match="a:para[@type='bold']"> <p><b><xsl:apply-templates/></b></p> </xsl:template> <xsl:template match="a:para"> <p><xsl:apply-templates/></p> </xsl:template>
In the long run, it will be more readable and more maintenable.
So, what should you do with the looping and test instructions? Think of them as shorthand for documents with a regular structure.
A table would be a good example. A table has a very regular structure (columns and cells within columns), so using the shorthand notation of a loop will be more readable. If in doubt, stick to the declarative style.
You will find that the declarative style is more powerful than the procedural one. Some concepts are trivial in the declarative style and nearly impossible to write with the procedural style.
You have covered lots of ground on XSLT already. In the next (and final) part in this series, you will learn about advanced features, such as calling scripts and working with multiple documents.
As an exercise until the next part, I encourage you to review the previous exercises. You have worked on both styles: declarative and procedural. Compare your style sheets and try to identify which style is most appropriate where. Did you make the right choice the first time around?
About the Author
Benoît Marchal is a Belgian writer and consultant. He is the author of XML by Example and other XML books. He is currently developing new training material on UML modelling and XML.