Abstract

XSLT processes documents by matching nodes in the document tree to templates, which then are executed to process these nodes. This process of matching and executing templates is the core of XSLT's processing model. XSLT has built-in templates which complement the user-supplied templates, so that the XSLT processor always finds a template to execute. Templates can conflict, and it is then necessary to resolve this conflict by finding the best match of all matching templates. This conflict resolution process also is a very important component of the XSLT processing model.

XSLT Programming

• Simple mappings can be defined in one template
  • the template creates the result document's structure
  • Iterations and Conditional Instructions provide some flexibility for processing
  • the resulting code is always spaghetti code
• Non-trivial XSLT programs use more than one template
  • different templates are responsible for mapping subtrees of the input document
  • the whole process is driven by the document
  • XSLT programming needs some time to get used to
• Like every tool, XSLT can be misused
  • for simple problems, XSLT can be used like a regular programming language
  • for harder problems, this is impossible (missing language constructs)

Input and Output

Templates as Building Blocks

• Templates are the main unit of code
  • the match attribute defines which nodes are processed by a template
  • whenever such a node needs to be processed, the template is executed (applied)
  • XPaths are interpreted with the matched node as context
• Templates contain a mix of Literal Result Elements and XSLT code
  • Literal Result Elements and tex nodes are copied to the result tree
  • XSLT elements are executed (depending on their semantics)
  • apply-templates plays a special role because it selects nodes to be processed
• The template application process is special
  • probably the most challenging aspect when learning the language
  • XSLT is much easier to use when understanding the underlying principle

Basic Mechanics

1. The source node list contains only the root node
2. The result tree is created by inserting the result from processing a node from the source node list
3. Processing typically puts more nodes on the source node list
4. The process is repeated until the source node list is empty

 <xsl:template match="*">
  <xsl:text>( Element:</xsl:text>
  <xsl:value-of select="local-name()"/>
  <xsl:apply-templates select="* | @*"/>
  <xsl:text>)</xsl:text>
 </xsl:template>

 <xsl:template match="@*">
  <xsl:text>Attribute: </xsl:text>
  <xsl:value-of select="local-name()"/>
 </xsl:template>

Template Selection

• Templates are connected through two statements
  • apply-templates selects which are put on the source node list
  • the XSLT processor selects the best template and executes it
• What happens if there is no template?
  • templates use Patterns to specify their applicability
  • users may not specify a template for a node they select
  • instead of an error, Built-In Templates are used to handle this situation

Patterns

• Patterns are a subset of XPath
  • they are used to specify to which nodes certain language constructs apply
  • patterns specify a set of conditions on a node
• The specification is short, but hard to understand
  • A node matches a pattern if the node is a member of the result of evaluating the pattern as an expression with respect to some possible context; the possible contexts are those whose context node is the node being matched or one of its ancestors.
• Practically, patterns are node tests, node contexts, and predicates
  • * matches any element
  • tr matches tr elements
  • thead/tr matches tr elements within thead elements
  • p[@class='warning'] matches p elements with their class set to warning
  • these mechanisms can be combined (and connected by the union operator |)

Pattern-Based Processing

    <ul>
     <xsl:for-each select="people/entry">
      <li>
       <xsl:value-of select="concat(name/pre[1], ' ', name/sur, ': ')"/>
       <xsl:apply-templates select="*[local-name() != 'name']"/>
      </li>
     </xsl:for-each>
    </ul>
   </body>
  </html>
 </xsl:template>
 <xsl:template match="email">
  <a href="mailto:{text()}" title="{text()}">✉</a>
  <xsl:text> </xsl:text>
 </xsl:template>
 <xsl:template match="phone">
  <a href="tel:{text()}" title="{@location}/{@type}:{text()}">☎</a>
  <xsl:text> </xsl:text>
 </xsl:template>
 <xsl:template match="affiliation"/>

XSLT Default Behavior

• Built into every XSLT processor
  • covering all seven XPath node types
  • the XSLT processor always finds a template to process a node
• Conflicts are thus also built into the language
  • every user template is in conflict with a built-in template
  • Conflict Resolution is a core concept of XSLT

Root and Elements

• The most important node types
  • every XML document has a root and at least one element
• The default behavior traverses the tree recursively
  • the recursion only selects child nodes (the default is select="node()")
  • attributes are not children of the elements nodes!

 <xsl:template match="* | /">
  <xsl:apply-templates/>
 </xsl:template>

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

</xsl:stylesheet>

Text and Attributes

• These nodes create text output
• the processing does not continue with apply-templates
  • text and attribute nodes are always leaf nodes
• Attributes are not selected by the built-in rules
  • they are only processed when selected by a user instruction

 <xsl:template match="text() | @*">
  <xsl:value-of select="."/>
 </xsl:template>

Processing Instructions and Comments

• These nodes are ignored
• Processing instructions and comments are selected by the built-in rules
  • the built-in behavior can be overwritten if required

 <xsl:template match="processing-instruction() | comment()"/>

Template Selection

• XSLT processes nodes on the source node list
• For processing each node, the best template must be found
• XSLT supports incremental development
  • templates can be added for more specialized processing
  • other code does not have to be changed at all
  • the source node list provides support for this decoupling
• For simple cases, the default mechanism is sufficient
  • advanced XSLT programming sometimes requires manual intervention

Template Selection

1. All templates with a match attribute
   • this excludes Named Templates
2. All templates with the same mode
   • part of the apply-templates instruction selecting the node
3. The Pattern must match
4. If more than one template matches, order by import precedence
   • the import tree of the stylesheet is considered (this includes the built-in rules)
5. If more than one template matches, order by priority
   • this sorts rules according to the specificity
6. Execute resulting rule
   • if still more than one, signal error or execute last in stylesheet

Import Precedence

Priorities

• Template priorities are computed
  • a very simple pattern-based process
  • a higher value means it is a better match
• Five steps are used to compute the priority
  1. templates using the union operator are treated as if there were multiple templates
  2. QNames and processing instructions are assigned a priority of 0
  3. Namespace-prefixed names are assigned a priority of 0.25
  4. other node tests with axis specifiers are assigned a priority of -0.25
  5. all other patterns are assigned a priority of 0.5

Different Conflicts

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:template match="/">
  <xsl:apply-templates select="descendant::a"/>
 </xsl:template>
 <xsl:template match="*"/>
 <xsl:template match="a"/>
 <xsl:template match="b/a"/>
 <xsl:template match="c/b/a"/>
</xsl:stylesheet>

<?xml version="1.0" encoding="UTF-8"?>
<c>
 <b>
  <a/>
 </b>
</c>

Resolution Process

Adjusting Priorities

• Computed priorities always lie between -0.5 and 0.5
• Non-trivial patterns almost always have the priority 0.5
• Priorities can be set explicitly
  • template match="..." priority="1"
• Managing priority values is up to the programmer
  • it is rarely necessary to manage a large set of competing priorities

Processing Nodes in XSLT

• XSLT supports to ways of processing nodes
  • Iterations loop over a set of selected nodes
  • Templates process nodes which have been put on the source node list
• Both mechanisms handle similar situations
  • a set of nodes is selected and should be processed
  • the code for processing has to available in a code block
  • Iterations put this code in the for-each body
  • Templates put this code in a reusable building block

Homogeneous Processing

• Iterations may lead to less modular code
• If the code has to be reused, they may not be a good solution
  • Named Templates may provide some support for reuse
• The selected nodes should require similar processing
  • otherwise, the iteration code will contain many conditional statements
• Iterations should be restricted to small units of code

Heterogeneous Processing

• If the node processing is very different, templates are better
  • different templates are written for all nodes being selected
  • no conditional code has to be written, selection is done by matching nodes to template patterns
• Templates can be reused
  • the nodes appear in different locations and should be processed consistently
  • the matching mechanism provides the ideal support for this scenario
• Extensible code should always use templates
  • other stylesheets can import an existing stylesheet
  • by selectively overwriting templates, the behavior can be customized

Executing Templates

• Templates usually have a match attribute
  • these templates are part of XSLT's special pattern matching processing
• Templates may also be named units of code
  • there is nothing special about these templates
  • they are being called using a name like regular procedures

Named Templates

• template may also carry a name attribute
• Named templates have none of the special properties of XSLT template matching
  • they are called by their name just like regular procedures
  • they do not change the context of XPath evaluation
• Named templates are useful for modularizing code which is not tied to node types
  • in most cases, they are called using Parameters
  • a typical application is the implementation of a facility for printing messages

Document-Driven Transformations

• XSLT often requires document-driven programming
• Imperative programmers are more used to control the program flow
• Document-driven processing is a powerful design principle
• Complex (highly variable) documents are much better handled by document-driven processing