XSLT Operation
XSLT is a rules-based, event-driven programming language. It is not a procedural language. Think of XSLT as a clerk who's in charge of a room filled with boxes. Each box does something useful. Figure 6-2 shows a template rule—which is a stand-alone object—waiting for an event defined by the match attribute. Once the rule receives an event, the rule can expose the content to other rules (apply-templates) or can output directly (value-of).
When an element comes along, the clerk selects a box based on certain criteria (usually events happening in the XML input document) and drops the result of those events into the box. Figure 6-3 illustrates this step.
Figure 6-2. An XML template rule encapsulates processing details, allowing the programmer to focus on input and output.
Figure 6-3. XSLT is analogous to a set of boxes that do mysterious processing inside. Depending on the processing, a box might output something for other boxes to process, something that is directly sent to the output, or nothing at all. Table 6-1 describes this processing in detail.
The processing happens in a box. Most of the time something comes out of that box. Depending on what the box does, this output might be static text, the result of calculations, or an element structure. The result that comes out will either go directly to the output or will be exposed to other boxes, which will process it further. I will show later how this process is done using the XSL transformation engine. In the following example, I'll walk you through the processing illustrated in Figure 6-3 with the simple XML document Curcon.xml:
<?xml version="1.0"?> <weather type="Current conditions"> <temp>76</temp> <wind>5</wind> </weather> |
I'll also use the XSL style sheet Weathersheet.xsl, shown in Listing 6-1.
Listing 6-1. Weathersheet.xsl, an XSL style sheet that formats weather data.
|
Table 6-1 describes the processing illustrated in Figure 6-3. You'll find the corresponding line numbers from Listing 6-1 in the description section of the table. Read through the description and see how each step is implemented in code.
Table 6-1. A step-by-step breakdown of the XSLT processing illustrated in Figure 6-3.
| Step in Figure | Description |
|---|---|
| 1 | One of the boxes is designed to process the weather element in the XML document. Since the weather element is the root element, the weather element and all of its descendants (an important fact to remember) are stuffed into the box. This box, with a square hole (as shown in Figure 6-3), is defined in the template rule on lines 6-10. |
| 2 | The first thing the box produces is some output. Using the <xsl:value-of/> element creates the text contents of the object in the select attribute. In this case, the content of the type attribute (@type) are sent out inside an HTML <H1> element. The XSL processor processes any element with the xsl: namespace prefix. Anything without the xsl: namespace prefix is sent verbatim to the output. The next command, <xsl:apply-templates/>, spits out the content of the weather element so that other boxes in the room can process it. |
| 3 | The first item contained inside weather is <temp>76</temp>. This is an element, and a box is waiting to process it—the one with a diamond-shaped hole. This box maps to the template rule on lines 12-14. |
| 4 | The HTML list item (<LI>) element start tag and the literal text "Temperature" do not have the xsl: namespace prefix, so they are sent directly to the output. |
| 5 | Now the box notices the <xsl:apply-templates/> element and, as with the weather element, spits out the content of the temp element, "76". This content can now be processed by another box. |
| 6 | The box with a donut hole is waiting. This box processes all text exposed by the other boxes. It is the template rule on lines 20-22. The single <xsl:value-of/> element will send the textual content of the thing that was captured (which can only be a textual element) directly to the output, which is indicated by the round hole in the front of the box. |
| 7 | After the text is processed, control returns to the "temp" rule, which outputs the end tag for the list item element. Once the temperature element has been processed, control reverts back to the weather template rule, where it waits to process the next child. |
| 8-12 | The wind element is that child, so the weather box spits out the wind element just like it spat out the temperature element, exposing the element to the boxes in the room. |
| 13 | After all children of the weather element have been processed, the <xsl:apply-templates/> element is finished and the rule continues to process the commands following it. In this case, there is a single HTML horizontal rule tag. It is sent to the output and processing terminates. |
Notice the syntax of the HTML horizontal rule tag in line 9. Remember that an XSL style sheet is a well-formed XML document. That means that it must adhere to the well-formedness constraints described in Chapter 4. Normally, the tag looks like this: <HR>. However, the horizontal rule tag is an empty element. Since the horizontal rule tag is included in line with the other XSL elements, it must also be well-formed, so it takes a slightly different form: <HR/>.
Recursive Processing
It is important to note that when a box spits out the content of an element for which it finds a match, the content is exposed to all the template rules, including the rule that created it. I'll demonstrate this with the short XSL program Generic.xsl, shown in Listing 6-2.
Listing 6-2. Generic.xsl, an XSL style sheet for generically processing any XML document to create a hierarchical view.
|
Notice that the style sheet in Listing 6-2 has no hard-coded element or attribute names. All elements are processed anonymously, according to their position in the document. We'll need ways to find out the names and types of each node that comes along, so we must build those capabilities into our style sheet that processes the document. Listing 6-3 shows the XML document 80112.xml, which I'm going to process.
Listing 6-3. 80112.xml, an XML document for our generic processing example.
|
Table 6-2 gives you a play-by-play of what happens when the style sheet in Listing 6-2 processes the XML document in Listing 6-3.
Table 6-2. A line-by-line breakdown describing the XSLT processing of the file 80122.xml using the Generic.xsl stylesheet.
| Line | Description | |
|---|---|---|
| 7 | The match="node()" rule will match just about any node that comes along. We are mostly interested in processing the element nodes, so node is a good choice. | |
| 8 | The first line of the match rule (line 8) has an HTML <DIV> element. A <DIV> is a breaking container that we can use to hold each element. Notice that <DIV> does not have an xsl: namespace declaration, so the <DIV> element will be sent directly to the output, along with its attributes. The STYLE attribute is an inline CSS style indicating the left margin of the <DIV>. | |
| 9 | The literal string [start does not have the xsl: namespace prefix, so it is sent to the output. Then the name of the element is output. By using the name node text inside the select attribute of the <xsl:value-of/> element, we are asking the node for its name—just as we ask it for its value when we use select=".". A literal ] follows the name of the element. The resulting output from this line takes the following form:
| |
| 10 | Until now, we have used only the <xsl:apply-templates/> element used by itself. Notice the select attribute on the apply-templates element. By default, the select attribute will select all nodes and expose them to all the templates in the style sheet. However, if we change the select attribute, we can restrict the kinds of nodes that we process. In this example, we want to process only attribute nodes. The pattern for selecting all attributes is "@*". | |
| 16 | Since our first element has an attribute (zipcode), this template rule in this line will catch it. | |
| 17-18 | The select="name()" node test returns the name of the attribute that was matched by the parser. In this template, an attribute was matched, so name returns the name of the attribute. The value of the attribute is processed the same way as the text value of an element node. The resulting output from this line takes the following form:
| |
| 11 | When the attributes finish processing, control returns to the line following the apply-templates element that exposed the attributes (line 11). This line is the unqualified apply-templates element, which will expose all the element children to all the template rules. | |
| 7 | Surprise! The first element in the <weather> element is <location>. The same rule that caught the root element <weather> will catch and process the <location> element also. | |
| 8 | Just as with the parent element, a <DIV> is generated with a cascading style of a 12-point left indent. Remember that when the <weather> element was processed, a 12-point left-indenting <DIV> appeared, but that <DIV> was not yet closed. The <DIV> for our <location> element is inside the <weather> <DIV>. One nice feature of cascading style sheets is (of course) that they cascade, which in this case means that everything inside the <location> element is indented 12 more points, to result in a 24-point indent. | |
| 11 | The content of the <location> element is processed on this line. A single text node is inside of this element, and that text node is caught by the rule that matches text in line 21. | |
| 21 | In the same way that the node test matches any element node, the text node test captures any contiguous string of text. | |
| 22 | The value of the text captured is output to the browser. Control returns to line 11, where parsing continues. | |
| 12 | After the content of each element is processed, we want to indicate some kind of ending notification. This line will output the name of the element that is currently being processed inside square brackets. | |
| 13 | The closing </DIV> tag marks the end of this 12-point indent. The indent level reverts back to where it was before the element was processed. | |
| 7-14 | This template rule will be called recursively (meaning it calls itself) for each element in the XML file until the entire document is processed. |
When we pop the resulting HTML output into our favorite Web browser, we can see that there is a nested representation of the information, as shown in Figure 6-4. The file in Figure 6-4 was created by using the transformNode() method of the Microsoft XML DOM implementation. We will see several different ways to use this method later.
Figure 6-4. A nested view of an XML document processed with the generic style sheet.
XSLT by Example
Let's try some other XSLT elements. Keep in mind the recursive nature symbolized by the room full of boxes. Consider the XML document Duckone.xml in Listing 6-4.
Listing 6-4. The Duckone.xml XML document used in the XSLT demonstration.
|
This document contains three elements named Joke. Each has a different value for the type attribute. Rules in the XSLT document Joke.xsl will individually process each element. Listing 6-5 contains the XSLT style sheet for this example.
Listing 6-5. The XSL style sheet Joke.xsl transforms an XML document for HTML output in the browser.
|
Table 6-3 provides a line-by-line description of the transformation implemented in the Joke.xml file in Listing 6-4.
Table 6-3. A line-by-line description of the transformation defined by the XSLT Joke.xsl.
| Line | Description |
|---|---|
| 4-6 | This XSLT program requires three namespaces. The first namespace contains Microsoft extensions to the XSLT language. The next namespace is required by the script element, as you'll see later. The XSLT processor requires the third namespace to know which version of XSLT to use. In this case, the processor will use the final XSLT Recommendation approved by the W3C in November 1999. |
| 8 | The xsl:output element declares the type of output desired. In this case, we want the output to adhere to the HTML version 4.0 specification. |
| 10-28 | This block of code is an example of script. The XSLT specification does not include a built-in scripting interface. Each implementer of the spec is responsible for designing a script interface if one is required. The Microsoft implementation offers a number of scripting options. In this case we're using Microsoft JScript. We'll use this script to create a string of HTML that represents the structure of an XML node. |
| 30-59 | When the XML document is loaded, the XML parser reads the document into the document object model tree and starts navigating the tree from the root. The root element, Jokes, will be processed first, and then the rest is processed. The first template matched will be for the first event generated. In this case, the template is the root element, Jokes. This rule defines the structure of the HTML document, including a CSS element. |
| 40 | The xsl:value-of element can call on a script defined by the XSLT implementation. In this case, the ShowXML function defined in line 12 is called, causing the text "Show XML" to be put inside of a span, with the contents of the current element (the argument, ".", passed to the function) put in the TITLE attribute. The net result is to create a string of text that has other text "behind" it—that is, when the user hovers the mouse pointer over the text "Show XML", the actual text of the element appears in a yellow pop-up window. |
| 41 | By default, the value-of element escapes the content it processes, meaning that all markup characters turn into their entity reference equivalents. For example, if a left angle bracket (<) is encountered, it is replaced with the entity reference for a left angle bracket, <. This replacement protects the XML output from interpreting literal characters in the text as markup. In our example, we don't want to use this kind of escaping, so we use the disable-output-escaping attribute to override the default behavior. |
| 45-54 | This section generates a table of contents based on the content of the document. |
| 46 | The xsl:for-each element establishes a collection of elements according to the select attribute. In this case, it will create a three-member collection of Joke element nodes. These members are processed by the content of the xsl:for-each element one member at a time. |
| 47-53 | In this section, the HTML A element encloses each item. |
| 48 | The xsl:attribute element adds an element to the currently open element. In this case, the element is A. The HREF attribute will be added with a value of a hash mark (#) and… |
| 49 | …the unique identifier of the member of the collection. The Microsoft XML parser assigns a locally unique identifier to each element in the document. You can access this unique identifier with the generate-id function. |
| 52 | The value of the type attribute on the Joke element is processed here. This value will be listed inside the <A> tag. |
| 53 | Notice the strange form of the HTML break tag (<BR/>). Remember that an XSLT style sheet is a well-formed XML document and thus must adhere to a number of well-formedness constraints defined by the XML spec. The HTML break tag, <BR>, is an empty element, and the HTML processor will interpret it properly if it looks like a normal start tag. However, because we are creating well-formed HTML, empty elements have a special form. In this case, the break tag appears as <BR/>. |
| 56 | The content of the node captured by the template element in the match attribute are exposed to all of the templates in the style sheet by this xsl:apply-templates element. This element will force document processing at this point. |
| 57-58 | Once the children are processed, the HTML BODY and HTML tags are closed. |
| 61-70 | Until this point, we have seen templates that sit around until an event in the input fires them. You can also create templates that act as subroutines that are called by other templates. Notice that this particular template does not have a match attribute. This kind of template is called a named template; it will be called by name from somewhere else. Named templates are similar to subroutines in any other language: you use named templates when you have a certain amount of processing to do and you don't want to repeat code in all the places that require the processing. |
| 62 | Named templates can interpret parameters passed from the calling rule. In this case, a parameter called author-alias is passed. |
| 66 | The author-alias parameter is put inside the HREF attribute of the HTML A element. |
| 68 | The author-alias value is repeated in this section. |
| 72-78 | The template set-name is another named template, but it does not require a parameter. This template will be called from somewhere else, and the required values are calculated internally within the template rather than being passed from an external call. |
| 80 | This template matches a joke, but only if it has an attribute named type that has a value of story. The string adheres to the XPath abbreviated form. |
| 81 | The named template on lines 72-78 is called here, causing any output produced by the named template to be output at this point. |
| 83 | Again, the showXML function is called, passing the content of the current element ".". |
| 86-90 | We invoke named templates with the xsl:call-template element. This element calls the email-author named template and passes the author-alias parameter equal to the value of the author attribute of the Joke element. |
| 92-95 | This particular type of Joke (type='story') contains a number of scenes, which the xsl:for-each element processes in order. |
| 93 | The literal text "Scene" is followed by the value of the number attribute and appears in bold. |
| 94 | The xsl:value-of element outputs the text content of the scene by using the select="." attribute, followed by a well-formed HTML break tag. |
| 139 | XSLT allows you to assign variable names to constant values. The xsl:variable element sets the value of the laughtrack variable. |
| 96 | The xsl:value-of element can output the content of predefined variables. In this case, the value of the laughtrack variable is output in italics following the story. |
| 99 | The next type of joke, knock-knock, is processed here. The processing is similar to the story joke. |
| 116 | The processing that occurred with the previous jokes occurs with a one-liner joke. |
| 131-133 | A knock-knock joke contains a number of lines—a structure similar to that of the story joke. In the story joke, however, we used the xsl:for-each structure to process the children. For knock-knock jokes, the content of the joke is processed on line 111. At that point, the template on line 131 is called. |
| 131 | Notice the match attribute. This returns a Line element, but only if the Line element is a direct child (indicated by the / separator) of a Joke element, and only if the Joke element has an attribute type with a value of knock-knock. As you can see, XPath patterns can get pretty detailed. |
| 135-137 | This section contains one last template to process quotes inside literal quotation marks. |
Transforming the XML document in Listing 6-4 with the XSL document in Listing 6-5 results in the HTML in Listing 6-6.
Listing 6-6. HTML output from the transformation of XML in Listing 6-4 with XSL in Listing 6-5.
|
Figure 6-5 shows the HTML output produced by the transformation. This output was created using the XSL transformation engine in XRay. The workspace is available on the companion CD at \Samples\Ch06\Chapter6.xrw. This will load the XML document, the XSL stylesheet, the transformation window, and an HTML browser window. We will use XRay to do this in the next section.
Figure 6-5. The resulting output of Listing 6-6, as seen in a Web browser. This figure shows both the XML document and the XSL style sheet in XRay, along with the resulting HTML and an example in the browser window. This example shows a pop-up window containing the source XML document, as contained in the TITLE attribute of the HTML SPAN element.
EAN: 2147483647
Pages: 150