Abstract

Because XML can be used to represent any vocabulary (often defined by some schema), the question is how these different vocabularies can be processed and maybe transformed into something else. This something else may be another XML vocabulary (a common requirement in B2B scenarios), or it may be HTML (a common scenario for Web publishing). Using XSL Transformations (XSLT), mapping tasks can be implemented easily. XSLT leverages XPath's expressive power in a rather simple programming language, the programs are often called stylesheets. For easy tasks, XSLT mappings can be specified without much real programming going on, by simply specifying how components of the source markup are mapped to components of the target markup.

XPath and XSLT

XPath is an expression language
- location paths let you select parts of an XML document tree
- expressions in general may have other data types as well (string, number, boolean)
XSLT is a programming language based on XPath
- XSLT defines the structures for the control flow within the program
- in all the places where something is evaluated, XPaths are being used
- sometimes, one can substitute for the other

  <xsl:for-each select=".//a">
   <xsl:if test="not(@title)">
    <xsl:text>This link has no title!</xsl:text>
   </xsl:if>
  </xsl:for-each>

  <xsl:for-each select=".//a[not(@title)]">
   <xsl:text>This link has no title!</xsl:text>
  </xsl:for-each>

XSLT Executive Summary

XSLT is an XML-oriented programming language
XSLT uses XML as its syntax
XSLT is a weakly typed language
XSLT is not designed for large programming tasks
XSLT is the standard language for XML-to-XML transformations
XSLT is very simple and often too simple
XSLT 2.0 is much more complex and powerful

XSLT as a Programming Language

XSLT is a functional programming language
- fundamentally different from the usual languages
- not important for very simple mapping applications
- important for writing more complex transformations
- hard to get used to for procedurally trained people
XSLT has built-in behavior for tree traversal
- XPaths allows you to select parts of the document tree
- XSLT's default behavior is to traverse the complete tree
- the idea of default behavior may seem strange

Outline (Simple Examples)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

My First XSLT

XSLT uses a simple environment
- all you need is an XSLT processor (Saxon recommended)
Some interesting observations
- it is an XML document (using the XSLT Namespace)
- it contains no visible code (no statements)
- when being applied (i.e., executed), it produces a result

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

</xsl:stylesheet>

Why does it Work?

The text of the document is produced
- technically, it is the concatenation of all text nodes
- this works with all XML input documents
XSLT by default traverses the document tree
- it copies all text nodes
- it works its way through the document recursively
- this behavior is unusual for a programming language

My Second XSLT

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

 <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>

</xsl:stylesheet>

How does it Work?

Text output rather than XML output
Overriding the default behavior
- new rules for how to recurse through the document tree
- the rules are applied by the XSLT processor
- the execution of the XSLT code is controlled by the XSLT processor
Traversing the document tree in XSLT is easy
- this is what XSLT has been designed for
- trying to avoid this pattern leads to bad code and bad results

My Third XSLT

 <xsl:output method="html"/>
 <xsl:template match="/">
  <html>
   <head>
    <title>Address List</title>
   </head>
   <body>
    <table>
     <xsl:for-each select="/people/entry">
      <tr>
       <td><xsl:value-of select="name/pre[1]"/></td>
       <td><xsl:value-of select="name/sur"/></td>
       <td><a href="mailto:{email}"><xsl:value-of select="email"/></a></td>
      </tr>
     </xsl:for-each>
    </table>
   </body>
  </html>
 </xsl:template>

How Mappings Work

All non-XSLT elements are literal result elements
- their content is processed as usual
- they may contain XSLT or literal result elements
XSLT elements in the stylesheet are instructions
- they are executed and have some predefined behavior
- if they produce results, these go to the result tree as well
One-template XSLT is a good way to start with XSLT
- avoiding the learning curve associated with Templates
- for easy mapping tasks, this pattern often is sufficient
- for complex tasks, this is the XSLT equivalent of spaghetti code

Hello World in XSLT

XSLT always transforms an XML document
- this is hard-coded in the XSLT Processing Model
Simply generating output is impossible
- hello world therefore ignores the input
- anything can be the input (including the XSLT itself)

<?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:text>Hello World!</xsl:text>
 </xsl:template>

</xsl:stylesheet>

Outline (XSLT Instructions)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

XSLT is RISC

XSLT has a small set of instructions
- the language was designed to run in a restricted environment
- the language was designed for a specific task
- much of the language's power lies in XPath
XPath is the CISC part of XSLT
- XPath is a complex high-level language
- it is specialized for the task the language is designed to do
- it can be highly optimized
- writing the XPaths often is the most challenging part of XSLT
Starting with XSLT should improve simple mappings

Iterations

XSLT can only iterate over node sets
- any other problem has to be solved recursively
- iterating over node sets often is what you want to do
Applying the same code to all of the nodes
- works great if all nodes require the same processing
- is of limited use when processing needs to be conditional

     <xsl:for-each select="/people/entry">
      <tr>
       <td><xsl:value-of select="name/pre[1]"/></td>
       <td><xsl:value-of select="name/sur"/></td>
       <td><a href="mailto:{email}"><xsl:value-of select="email"/></a></td>
      </tr>
     </xsl:for-each>

Conditional Instructions

Programming languages usually provide if-then-else
- XSLT has an if-then: if
- and a if-then-(elif-then)*-else: choose
Simple handling of special cases
- having few and reasonably sized conditionals is ok
- having deeply nested and very long conditionals is a problem
- as in all programming languages, the latter case should user other mechanisms

My Third XSLT (II)

    <table>
     <xsl:for-each select="/people/entry">
      <tr>
       <td><xsl:value-of select="name/pre[1]"/></td>
       <td><xsl:value-of select="name/sur"/></td>
       <td>
        <xsl:if test="email">
         <a href="mailto:{email}"><xsl:value-of select="email"/></a>
        </xsl:if>
       </td>
      </tr>
     </xsl:for-each>
    </table>

My Third XSLT (III)

       <td>
        <xsl:for-each select="phone">
         <xsl:text>☎ (</xsl:text>
         <xsl:choose>
          <xsl:when test="@location = 'office'">Office</xsl:when>
          <xsl:when test="@location = 'home'">Home</xsl:when>
         </xsl:choose>
         <xsl:text> </xsl:text>
         <xsl:choose>
          <xsl:when test="@type = 'voice'">phone</xsl:when>
          <xsl:when test="@type = 'fax'">fax</xsl:when>
         </xsl:choose>
         <xsl:text>): </xsl:text>
         <xsl:value-of select="."/>
         <xsl:if test="position() ne last()">
          <br/>
         </xsl:if>
        </xsl:for-each>
       </td>

Outline (XSLT Processing Model)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

XSLT Programming

Stylesheets (XSLT programs) are a set of templates
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)

Outline (Templates)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

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
- 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

The source node list contains only the root node
The result tree is created by inserting the result from processing a node from the source node list
Processing typically puts more nodes on the source node list
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:{.}" title="{.}">✉</a>
  <xsl:text> </xsl:text>
 </xsl:template>
 <xsl:template match="phone">
  <a href="tel:{.}" title="{@location}/{@type}:{.}">☎</a>
  <xsl:text> </xsl:text>
 </xsl:template>
 <xsl:template match="affiliation"/>

Outline (Built-In Templates)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

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()"/>

Outline (Conflict Resolution)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

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

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

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

Pattern	Priority	Resolution Step					Manual Adjustment
Pattern	Priority	1	2	3	4	5	Manual Adjustment
Built-in: `text() \| @*`		✓	✓
Built-in: `* \| /`		✓	✓	✓
`*`	-0.5	✓	✓	✓	✓
`a`	0.0	✓	✓	✓	✓
`b/a`	0.25	✓	✓	✓	✓	✓
`c/b/a`	0.25	✓	✓	✓	✓	✓	`priority="1"`

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

Outline (How to Iterate)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

Processing Nodes in XSLT

XSLT supports two 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

Outline (Calling Templates)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

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

Outline (Variables and Parameters)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

Programming Language Basics

Variables in programming languages have different purposes
1. defining a name for something so that it can be referred to
2. associating this name with a value so that the value can be used
3. providing a way to update the variable so that its value changes
Variables in functional languages cannot change
- they are immutable (often called constants in other languages)
- more specifically, they are dynamic constants (i.e., can be computed at runtime)
- they are defined by giving them a name and referred to by $name
Variables in XSLT have no type (no static type checking possible)
- the value that they have is typed
- but a variable may have values of any type

<xsl:variable name="sum" select="$op1 + $op2"/>
<xsl:variable name="result" select="$sum * $factor"

Outline (Variables)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

Why Variables?

Reuse of values in different locations

texts required for the transformation
facilitates better separation of structure and content

<xsl:value-of select="$email-prefix"/> <!-- $email-prefix = 'You have ' -->
<xsl:value-of select="count(//message)"/>
<xsl:value-of select="$email-suffix"/> <!-- $email-suffix = ' e-mail messages.' -->

Using the correct context is essential
- variables cannot be updated
- if they need to be updated, they have to be re-created
Why are they called variables if they are constants?
- their value varies in different invocations of the context
- they are computed at runtime (dynamic constants) rather than statically

Scope and Extent

Variables can be global or local
- global variables are visible in all templates
- local variables are visible in their context (i.e., at following-sibling::*/descendant-or-self::*)
- local variables are allowed to shadow global (not local) variables
Variable values may be assigned using the select attribute
- The XPath's result is the value of the variable
Variables can contain arbitrary XPath code
- the code is executed in the same way as when constructing the result tree
- the result tree fragment is the value of the variable
- it can be used as a string (value-of) or as a tree (copy-of)

Using Variables

 <xsl:variable name="name" select="'value'"/>
 <xsl:template match="/">
  <xsl:choose>
   <xsl:when test="$name = 'value'">
    <xsl:variable name="result" select="'ok'"/>
   </xsl:when>
   <xsl:otherwise>
    <xsl:variable name="result" select="'problem'"/>
   </xsl:otherwise>
  </xsl:choose>
  <xsl:value-of select="$result"/>
 </xsl:template>

 <xsl:variable name="name" select="'value'"/>
 <xsl:template match="/">
  <xsl:variable name="result">
   <xsl:choose>
    <xsl:when test="$name = 'value'">
     <xsl:value-of select="'ok'"/>
    </xsl:when>
    <xsl:otherwise>
     <xsl:value-of select="'problem'"/>
    </xsl:otherwise>
   </xsl:choose>
  </xsl:variable>
  <xsl:value-of select="$result"/>
 </xsl:template>

Outline (Parameters)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

Parameters vs. Variables

Parameters are variables with additional semantics
- they are passed to their scope from the outside
- they are available within the scope like a variable (scopes are stylesheets and templates)
- like variables, they cannot be updated (and only global parameters can be shadowed)
XSLT does not check proper parameter passing
- if a declared parameter is not passed, it gets a default value (specified or '')
- if a passed parameter is not declared, it is ignored
- like variables, parameters have no type (any value can be passed)
- XSLT's robustness makes it hard to spot programming errors

Stylesheet Parameters

Passed to the stylesheet when calling the stylesheet
- the exact way of specifying the parameters depend on the processor and the environment
- the passed values are available in the same way as global variables
- parameter checking has to be done by hand

 <xsl:param name="number" select="0"/>
 <xsl:variable name="number-param">
  <xsl:if test="string(number($number)) = 'NaN'">
   <xsl:message terminate="yes">"number" must be a proper number!</xsl:message>
  </xsl:if>
  <xsl:value-of select="$number"/>
 </xsl:variable>
 <xsl:template match="/">
  <xsl:value-of select="10 * $number-param"/>
 </xsl:template>

Template Parameters

Parameters can be passed to templates
- works with apply-templates and call-template
- with-param elements list the passed parameters
- parameter matching is done by name (there is no particular order to parameters)
Templates can be programmed as parametrized components
- checking the signature has to be done by hand
- with-param elements list the passed parameters
- parameter matching is done by name (there is no particular order to parameters)
Parametrized template calls need a lot of markup
- XSLT's XML syntax makes the code hard to read

main param start = 1 ; param count = 10 ; {
	loop (0) };
loop param counter ; {
	print $start + $counter ;
	if ( $counter < $count - 1) then 
		loop ($counter + 1) ; }

Parameter Passing

 <xsl:param name="start" select="1"/>
 <xsl:param name="count" select="10"/>
 <xsl:template match="/">
  <xsl:call-template name="loop">
   <xsl:with-param name="counter" select="0"/>
  </xsl:call-template>
 </xsl:template>
 <xsl:template name="loop">
  <xsl:param name="counter"/>
  <xsl:message>
   <xsl:value-of select="$start + $counter"/>
  </xsl:message>
  <xsl:if test="$counter &lt; $count - 1">
   <xsl:call-template name="loop">
    <xsl:with-param name="counter" select="$counter + 1"/>
   </xsl:call-template>
  </xsl:if>
 </xsl:template>

Message Facility

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:param name="message" select="'plain'"/>
    <!-- messaging style: 'silent', 'plain', or 'prefixed' -->
    <xsl:template name="message">
        <xsl:param name="level" select="'fatal'"/>
        <!-- message level: 'warning', 'error', or 'fatal' -->
        <xsl:param name="text" select="'no text given'"/>
        <xsl:choose>
            <xsl:when test="$message = 'silent'"/>
            <xsl:when test="$level = 'warning'">
                <xsl:call-template name="print_message">
                    <xsl:with-param name="level" select="'warning'"/>
                    <xsl:with-param name="terminate" select="'no'"/>
                    <xsl:with-param name="text" select="$text"/>
                </xsl:call-template>
            </xsl:when>
            <xsl:when test="$level = 'error'">
                <xsl:call-template name="print_message">
                    <xsl:with-param name="level" select="'error'"/>
                    <xsl:with-param name="terminate" select="'no'"/>
                    <xsl:with-param name="text" select="$text"/>
                </xsl:call-template>
            </xsl:when>
            <xsl:when test="$level = 'fatal'">
                <xsl:call-template name="print_message">
                    <xsl:with-param name="level" select="'fatal'"/>
                    <xsl:with-param name="terminate" select="'yes'"/>
                    <xsl:with-param name="text" select="$text"/>
                </xsl:call-template>
            </xsl:when>
            <xsl:otherwise>
                <xsl:call-template name="print_message">
                    <xsl:with-param name="level" select="'fatal'"/>
                    <xsl:with-param name="terminate" select="'no'"/>
                    <xsl:with-param name="text" select="concat('fatal:unknown level for message [', $text, ']')"/>
                </xsl:call-template>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>
    <xsl:template name="print_message">
        <!-- this template should never be called from outside; for printing messages, call the "message" template. -->
        <xsl:param name="level"/>
        <xsl:param name="terminate"/>
        <xsl:param name="text"/>
        <xsl:choose>
            <xsl:when test="$message = 'plain'">
                <xsl:message terminate="{$terminate}">
                    <xsl:value-of select="$text"/>
                </xsl:message>
            </xsl:when>
            <xsl:otherwise>
                <xsl:message terminate="{$terminate}">
                    <xsl:value-of select="concat($level, ':', $text)"/>
                </xsl:message>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>
</xsl:stylesheet>

Outline (Controlling Documents)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

XSLT Processing Model

XSLT was built as a client-side language
- the browser has an XML document
- the XSLT is used to transform this XML
- the result is used for rendering the formatted document
XSLT provides facilities for accessing additional documents
- an additional XML might contain localized texts for rendering
- like everything in XSLT, identification uses URIs

Outline (Input Documents)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

Opening Documents

Initially, XSLT starts with the XPath node tree of the main document
- this step is outside of the control of the XSLT programmer
Additional documents can be accessed using document()
- the function accepts URIs, which are interpreted relative to the stylesheet
- only XML documents can be used, they will be parsed into an XPath tree
XSLT Processors are smart enough to cache documents
- re-opening the same document will not re-parse it

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:output method="text"/>
 <xsl:template match="/">
  <xsl:text>me: </xsl:text>
  <xsl:value-of select="count(document('document.xsl')/descendant::*)"/>
  <xsl:text>&#xa;http://dret.net/netdret/publications: </xsl:text>
  <xsl:value-of select="count(document('http://dret.net/netdret/publications')/descendant::*)"/>
 </xsl:template>
</xsl:stylesheet>

Whitespace in Documents

Documents often contain many irrelevant whitespace text nodes
- many XML documents are pretty-printed for readability
- pretty-printing produces many line-feeds and tabs/spaces
XSLT can be instructed to ignore whitespace nodes
- strip-space lists all elements for which whitespace children should be ignored
- this may be a bit too much, because Mixed Content may contain significant whitespace
```
do not throw away these whitespace nodes!
```
XSLT can be instructed to preserve some whitespace nodes
- preserve-space lists all elements for which whitespace children should be preserved
- usually, preserve-space lists the exceptions for strip-space
- usually, preserve-space contains a list of all mixed content elements

Controlling Whitespace

 <xsl:strip-space elements="*"/>
 <xsl:preserve-space elements="xsl:text"/>
 <xsl:template match="/">
  <xsl:text>xsl:text is used for outputting text.</xsl:text>
  <xsl:text> </xsl:text>
  <xsl:text>it also is the only element where whitespace nodes in the stylesheet are significant</xsl:text>
  <xsl:text>&#xa;</xsl:text>
  <xsl:value-of select="count(//text())"/>
 </xsl:template>

Outline (Output Documents)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

Serialization

XSLT always produces a result tree
- stylesheet processing starts with an empty tree (root node only)
- XSLT code producing output then adds nodes to this tree
- text, value-of, copy-of, copy, element, attribute, comment, processing-instruction, Literal Result Elements
Serialization is the process of externalizing the final tree
- output controls how the tree is serialized
- xml writes the tree as an XML document
- html writes the tree as an HTML document (img ... instead of img .../)
- text writes the tree's string value (the concatenation of all text nodes)

Multiple Output Documents

XSLT 1.0 does not support more than one output document
- message is another output channel, but not a document
- this was one of the most requested features for language improvements
How can stylesheets produce more than one document?
- XSLT 1.0 may produce one document which is then post-processed
- XSLT 2.0 offers language facilities for more than one output document

Outline (Keys)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

Document Access

Some parts of documents may be accessed frequently
- //person[@ss = $ss]/name/surname for getting a name by social security number
- costs depend on document size and access frequency
- the document structure has to be used in all places where the name is used
Keys provide access to frequently used nodes
- key('ssKey', $ss)/name/surname is based on a predefined access path (the key)
- very easy to optimize even for very simple XSLT processors
- easier to understand from the programmer's point of view
For nested predicates, non-optimized evaluation is very expensive
- //reference[@crossref = //reference[@title = $title]/@name]

Declaring and Using Keys

key defines a key on the stylesheet's top level
- key name="ssKey" match="person" use="@ss"/
- name is used for referring to the key (most people use ...Key)
- match selects all nodes which will be part of the key (i.e., accessible through it)
- use selects the value(s) which will retrieve the nodes
key() is used for retrieving nodes from a key
- the first argument specifies the name of the key (defined by key name="..." ...)
- the second argument specifies the value for which to look in that key
- key() returns a node set (empty or any number of nodes)

XML and XSLT for using a Key

<people>
 <entry id="dret" country="de">
  <name>
   <pre>Erik</pre>
   <pre>Thomas</pre>
   <sur>Wilde</sur>
  </name>
  <email>dret@berkeley.edu</email>
  <affiliation country="us">iSchool/UCB</affiliation>
  <phone location="office" type="voice">+1-510-6432253</phone>
  <phone location="office" type="fax">+1-510-6425814</phone>

 <xsl:key name="preNameKey" match="name" use="pre"/>
 <xsl:key name="affiliationKey" match="affiliation" use="."/>
 <xsl:key name="countryKey" match="entry | affiliation" use="@country"/>

key('preNameKey', 'Thomas') ≡ //name[pre = 'Thomas']

XSLT Key Structure

preNameKey
Node	Value
[1] Erik Thomas Wilde	Erik
[1] Erik Thomas Wilde	Thomas
[2] Thomas Plagemann	Thomas
[3] Bob Glushko	Bob

countryKey
Node	Value
[1a] Erik Thomas Wilde	de
[1b] iSchool/UCB	us
[2a] Thomas Plagemann	de
[2b] IFI/UIO	no
[3a] Bob Glushko	us
[3b] iSchool/UCB	us

Using Keys

Finding nodes by intersecting key() results
- key() always returns node sets
- interesting sets of nodes may be the intersection of several keys
- unfortunately, XPath does not provide an operator for set intersection

Node Set Intersection

$a[count(. | $b) = count($b)]: Find all nodes in $a where the cardinality of $b does not change when adding this node to it. This means the node must be in $b, and it is in $a to start with.

Outline (Generating Result Nodes)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

Literal Result Elements

Non-XSLT elements are copied to the result tree
- this is the most common way of producing nodes
- in this case, the nodes' names are hard-coded in the stylesheet
Attributes are also copied to the result tree
- this means the attribute will always be there
- conditional creation of attributes needs other language constructs

Producing Nodes Explicitly

Element nodes can be produced by using element
- the element name must be specified and can be computed
- additional instructions exist for all node types

 <xsl:template match="*">
  <xsl:element name="{translate(local-name(), 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')}">
   <xsl:apply-templates select="node() | @*"/>
  </xsl:element>
 </xsl:template>
 <xsl:template match="@*">
  <xsl:attribute name="{translate(local-name(), 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')}">
   <xsl:value-of select="."/>
  </xsl:attribute>
 </xsl:template>

Outline (Modularizing Stylesheets)

Simple Examples [7]
XSLT Instructions [5]
XSLT Processing Model [18]
1. Templates [5]
2. Built-In Templates [4]
3. Conflict Resolution [7]
How to Iterate [3]
Calling Templates [2]
Variables and Parameters [9]
1. Variables [3]
2. Parameters [5]
Controlling Documents [6]
1. Input Documents [3]
2. Output Documents [2]
Keys [6]
Generating Result Nodes [2]
Modularizing Stylesheets [2]
Conclusions [1]

Including and Importing

XSLT supports two ways of modularizing code
- including simply distributes code across multiple files
- importing creates a dependency and a hierarchy
include is mainly used for keeping files manageable
- it is used within managed projects
import is mainly used for reusing code from elsewhere
- it imports reused code and assigns this code a lower precedence
- local instructions can then overwrite (if required) some of the imported code

XSL Transformations (XSLT)

Information Systems and the World Wide Web

International School of New MediaUniversity of Lübeck

Erik Wilde, UC Berkeley School of Information2007-01-10

Abstract

XPath and XSLT

XSLT Executive Summary

XSLT as a Programming Language

Outline (Simple Examples)

My First XSLT

Why does it Work?

My Second XSLT

How does it Work?

My Third XSLT

How Mappings Work

Hello World in XSLT

Outline (XSLT Instructions)

XSLT is RISC

Iterations

Conditional Instructions

My Third XSLT (II)

My Third XSLT (III)

Outline (XSLT Processing Model)

XSLT Programming

Input and Output

Outline (Templates)

Templates as Building Blocks

Basic Mechanics

Template Selection

Patterns

Pattern-Based Processing

Outline (Built-In Templates)

XSLT Default Behavior

Root and Elements

Text and Attributes

Processing Instructions and Comments

Outline (Conflict Resolution)

Template Selection

Template Selection

Import Precedence

Priorities

Different Conflicts

Resolution Process

Adjusting Priorities

Outline (How to Iterate)

Processing Nodes in XSLT

Homogeneous Processing

Heterogeneous Processing

Outline (Calling Templates)

Executing Templates

Named Templates

Outline (Variables and Parameters)

Programming Language Basics

Outline (Variables)

Why Variables?

Scope and Extent

Using Variables

Outline (Parameters)

Parameters vs. Variables

Stylesheet Parameters

Template Parameters

Parameter Passing

Message Facility

Outline (Controlling Documents)

XSLT Processing Model

Outline (Input Documents)

Opening Documents

Whitespace in Documents

Controlling Whitespace

Outline (Output Documents)

Serialization

Multiple Output Documents

Outline (Keys)

Document Access

Declaring and Using Keys

XML and XSLT for using a Key

XSLT Key Structure

Using Keys

Node Set Intersection

Outline (Generating Result Nodes)

International School of New Media
University of Lübeck

Erik Wilde, UC Berkeley School of Information
2007-01-10