home—lects—exams—hws
D2L—breeze (snow day)

lect13a
XSLT, cont.
generating attributes; templates

To create attributes: (that is, using XSLT to insert attributes into the xml/html node being generated)

            <xsl:attribute name="att_name">
              <!-- Here, specify the value of the new attribute.
                   Of course, you can use any XML: literal, or and XSLT instructions.
                   This body gets spliced into the enclosing tag (!) -->
            </xsl:attribute>

Suppose we want each Wonder to be a link — that is instead of the plain text “Colossus of Rhodes” we want to generate “<a href="#Colossus%20of%20Rhodes">Colossus of Rhodes</a>”. However, we can't do this with the xsl directives above(!)¹ — we can either use pre-determined html, or select expressions from a tree as text, but not select an expression which gets put mid-tag as an attribute. That's where xsl:attribute comes to the rescue:

            <a>
               <xsl:attribute name="href"> 
                 #<xsl:value-of select="../wonder/name" />  <!-- link-target -->
               </xsl:attribute> 
               <xsl:value-of select="../wonder/name" /> <!-- link-text -->

evaluates to the desired node, <a href="#Colossus%20of%20Rhodes">Colossus of Rhodes</a>.
lect12a-ch02-attributes.xml
lect12a-ch02-attributes.xsl

(Like xsl:sort, this is another weird placement; we put the xsl:attribute inside the parent tag's body, but the xsl:attribute doesn't affect our parent's body — it affects the parent itself.)

Defining templates for re-use, and calling(applying) them:

The root template is the first thing processed in an XSLT style sheet. XSLT allows you to create more templates than just the root template. This allows you to create different sets of processing rules to apply to different parts of the XML document.

One of the main benefits of using templates is the ability to reuse a template for other nodes in your document. In the same way that one can use functions in most programming languages, you would create a template, and simply apply that template whenever necessary. This eliminates the need to repeat the same processing instructions.

In our ongoing example: We have been putting the non-english name in parentheses and italics. Suppose we want to do that throughout, consistently, and make it easy to maintain any changes or tweaks to this decision. We can define a template to process non-English name nodes, and then apply it in different contexts. (E.g. if there are tags for “newspaper”, we could apply the same template for non-English names there.)

                <!-- Define the function -->
                <xsl:template match="name[@language!='English']">
                   (<em><xsl:value-of select="."/></em>)
                </xsl:template>

As mentioned above, we call that function using apply-templates:
lect12a-ch02-demo-templates.xsl
lect12a-ch02-demo-templates.xml

The system looks for and calls the template for "/" automatically; other templates are only invoked via apply-templates.

There is a default template that gets called, if one doesn't otherwise apply: For a text node, just return the text; for a tag node, recursively call apply-templates on all its children.

You can't provide other arguments to templates — just the xpath of the element to process. And you can't call templates on any ol' node — you must specify (when you create the template) what xpaths it applies to.

Note that even when ~~calling a function~~ applying a template (so that your xsl:apply-templates tag has no body), you still can have a xsl:sort tag inside:

    <xsl:apply-templates select="ancient_wonders/wonder">
      <xsl:sort select="height" order="descending" data-type="number" />
    </xsl:apply-templates>

One data file, many pages

Similar to how a web-page (data) can have a css-stylesheet directive (processing), XML data files have a xml-stylesheet tag, with what XSLT file processes them.

It's annoying, that the xml-stylesheet processing instruction should be in the same file as the raw XML data. What if you have one data file, and you want to use it to produce several different views/results? Alas, the usual solution is to fall back to a different technology: Have a php file which prints the xml-stylesheet line, and then require's the XML file:

// The file children.php:
<?xml-stylesheet type="text/xsl" href="children.xsl"?>
<?php
  require('children-data.xml');
?>

In fact, this might happen often enough that you choose to write a php util function — say, renderXMLWith([string] $xmlDataFile, [string] $xslTransformFile ) — which prints out these lines. (So the file being linked to (children.php) actually contains just two lines: requiring utils.php, and then a call to renderXMLWith).

¹ In php it's no problem to have an expression whose result was inserted into the middle of an attribute. However, since XSLT is itself written in XML, and XML of course doesn't allow opening a tag in the middle of an attribute, the syntax physically precludes putting xls:select (etc.) expressions in the middle of an attribute. ↩

home—lects—exams—hws
D2L—breeze (snow day)

©2012, Ian Barland, Radford University
Last modified 2013.Apr.26 (Fri) Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu

lect13a XSLT, cont.generating attributes; templates

One data file, many pages

lect13a
XSLT, cont.
generating attributes; templates