This chapter is from the book
This chapter is from the book
This chapter is from the book
XSLT
It's only natural to transition from CSS to XSLT (Extensible Stylesheet Language for Transformation) programming. Although CSS helps us assign styles to style-free XML content in a passive, rule-based manner, XSLT actually rolls up its sleeves and restructures an XML document. There are three ways to render an XML/HTML document:
Associate CSS declaratives with the markup document, and rely on the browser to process the style instructions.
Use XSLT to transform the document using XSL, giving even greater control over how the document is to be rendered spatially and stylistically. This can occur on either the client or server.
Focus on server-side processing, using XSLT (or Java programming) to transform the document completely to HTML, XHTML, or WML.
XSLT has gained popularity as a nifty, lightweight programming language for transforming XML into a variety of presentations. It also plays a significant role in the back end, where "data integration" is a hot topic in B2B and old-style EAI applications. XSLT transforms or re-purposes industry-defined XML documents generated by a remote application into a format that is familiar to the local host application.
XSLT is the most successful aspect, so far, of the XSL standard from the W3C.org folks. Much of the fanfare around XSL was the FO (Format Object), which has yet to find a large audience other than with the Cocoon community, discussed later. Instead, it's the XSLT mechanism that is ruling the day. People want what is useful and compelling. XSLT is that kind of technology. FOs in many ways are redundant with the functionality of CSS, having, in fact, incorporated some of the CSS functionality, as illustrated in Figure 3.2.
){kind=link}
Figure 3.2 The somewhat redundant relationship of CSS to XSL, both products of W3C.org.
Illustrated in Figure 3.3, XSLT can be used to transform a single XML document into multiple documents that are specific to the manufacturers, for example, that use its contents to build products. For example, each shoe manufacturer might have its own way of defining a shoestring. Adidas might deal with shoestrings described as
){kind=link}
<?xml version="1.0" encoding="UTF-8"?> <Shoestrings> <shoestring color="white" length="12" units="inches"/> <shoestring color="blue" length="16" units="inches"/> <shoestring color="blue" length="12" units="inches"/> <shoestring color="green" length="10" units="inches"/> </Showstrings>
whereas Nike might recognize the shoestrings in their own format of
<shoe> <string> <color>white</color> <length>12</length> <units>inches</units> </string> </shoe>
XSLT can easily make the transition from one format, perhaps based on a shoe industry consortium's official XML standard, to one that they prefer for their legacy applications.
Figure 3.3 XSLT re-purposes a single document to suit multiple client applications.
Note
Speaking of shoes, Customatix.com is one of Enhydra XMLC's first and most successful commercial deployments. Built as an Enhydra-powered site for former executives from Adidas, this site uses XMLC and a single Java Applet to give the visitor the capability to select a basic shoe or boot model, then completely alter it, colors, materials, graphics and all. XMLC is also used to deliver build instructions in XML format for the manufacturing of the customer's shoes.
How XSLT Works
Representing the form of an instruction tree, an XSLT document drives an XSLT processor to turn an XML document (source tree) into another XML document (result tree). Collectively, XSLT instructions represent a special type of XML document as indicated by the following lines of an empty XSLT document:
<?xml version='1.0'?> <xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'> ... </xsl:stylesheet>
Template expressions guide the transformation process using Xpath naming to identify one or more nodes in the source tree for treatment. A template rule is represented by the XML element <template>. The template element's attribute represents the selection process by which the template rule identifies the level of the source tree.
There are 34 elements supported by one or more attributes. Some of them are clearly program logic-like commands such as for-each, if, otherwise, sort, when, and variable. But even restricting your uses of XSLT elements to only a few, particularly apply-templates and value-of, impressive transformations are possible.
XSLT uses Xpath to reference a relative position in the source tree based on your current position. In the following example, the template element, using the match attribute, identifies all the Xpaths to every occurrence of the element units in our earlier shoe string example:
<xsl:template match="shoestring/units"> <units>cm</units> </xsl:template>
In this example, the purpose of matching every units element is to generate a new result tree that uses centimeters instead of inches to determine the shoestring length. But of course, this is only a partial conversion, because we haven't addressed the conversion of the length itself.
Listing 3.6 simply constructs an HTML table of shoestring colors, lengths and length units. Listing 3.7 is another version of the same transformation, with the exception of the introduction of shoestring lengths as calculated in centimeters.
Listing 3.6 Creating an HTML Table Shoestring Attribute
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="html" indent="yes" />
<xsl:template match="Shoestrings">
<table>
<tr><th>Color</th><th>Length</th><th>Units</th></tr>
<xsl:apply-templates />
</table>
</xsl:template>
<xsl:template match="shoestring">
<tr>
<td>
<xsl:value-of select='@color'/>
</td>
<td>
<xsl:value-of select='@length'/>
</td>
<td>
<xsl:value-of select='@units'/>
</td>
</tr>
</xsl:template>
</xsl:stylesheet>
Listing 3.7 Updating the Length Value to Reflect the Units Change
<xsl:template match="shoestring">
<tr>
<td>
<xsl:value-of select='@color'/>
</td>
<td>
<xsl:value-of select={'@length' / 2.54} />
</td>
<td>cm</td>
</tr>
</xsl:template>
</xsl:stylesheet>
Note
XSLT support is incorporated into Enhydra by virtue of Apache's Xalan XSLT processor. The examples given here were tested using Lutris Enhydra 3.5.
Do the roles of XSLT and XMLC overlap? You bet. But there are differences that might drive you one way or the other. For one, XSLT performance can be a problem, particularly as you come up with more complex transformations. Secondly, if you're in a Java environment running XSLT transformations, error handling can be a bit tricky. To avoid this situation, upfront testing of anticipated transformations is a must.
XSLT Summary
On its own merits, XSLT is clear, at times elegant, and like Perl, appears cryptic enough to fascinate the nerd in all of us. XSLT processing has emerged as a serious candidate enabling XML-based presentations to adapt on-the-fly to all those mobile phones and other yet-to-be-defined devices that will eventually chat with application servers. There is little that XSLT cannot do to modify an XML document. XSLT contains all the capability to make conditional tests, sort data, and leverage built-in functions for conducting serious transformations.
XSLT can be used in a number of roles, including processing XML for presentations. For example, different XSLT instructions can be used, depending on the device that is being displayed to. The Enhydra application server incorporates the Apache Xalan XSLT parser, making it possible to combine Java development, XMLC programming, and XSLT transformations.
An XSLT strategy appears to be a good one if you don't mind supporting multiple languages for your application, namely Java and XSLT. If that's not an issue, be sure to consider performance characteristics of XSLT processing, because it does not benefit from fast Java compilers.
I thought that Erik Ray, author of O'Reilly's Learning XML said it best: "To do anything sophisticated with XSLT, we have to move around the document as nimbly as a monkey in the tree."