XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (35 page)

These weak conversions are applied to the values of variables and parameters, and they are also used when converting the arguments supplied in a function call to the types declared in the function signature.

Strong conversions can be achieved by use of constructor functions; for example, you can convert a string to an integer with the function
xs:integer($s)
. Generally in XSLT 2.0, strong conversions are not applied automatically; you have to ask for them. Strong conversion is also referred to as
casting
, and the rules for casting are given in Chapter 11.

In the case of function calls, strong conversions are sometimes applied implicitly if you run the stylesheet in backward-compatible mode. This is described in Chapter 3 on page 128. You can select backward-compatible mode by specifying
version=“1.0”
on the

element. However, even in backward-compatible mode strong conversions are not applied to variables and parameters in the stylesheet. This is because in XSLT 1.0 it was not possible to declare the type of a variable or parameter, so there is no requirement here for backward compatibility.

Parameters

Parameters in XSLT are very similar to variables. They are declared with an

element instead of

, and they differ in that the value can be supplied externally. There are three places you can use parameters in a stylesheet:

• Stylesheet parameters
  (also known as global parameters) are supplied when the transformation is invoked, and they can be referenced from anywhere in the stylesheet. They are set from outside the stylesheet (for example, from the command line or from an API—the actual mechanism is implementation defined).
  
• Template parameters
  are defined within an
  
  element, and are available only during the evaluation of that template. They are set by means of
  
  elements within the instruction (for example
  
  or
  
  ) that invokes the template. These parameters can take different values each time the template is invoked.
  
• Function parameters
  are defined within an
  
  element, and are available only during the evaluation of that function. Functions are very similar to named templates, except that they are invoked not by means of XSLT instructions but by evaluating a function call within an XPath expression. The parameters to a function are supplied as part of this function call.
  

As with variables, the expected type of a parameter can be declared using an
as
attribute. Here it's especially useful to declare the expected type, because you can then fail cleanly if the caller supplies the wrong type of value, rather than crashing or producing wrong answers. It's also very valuable to the XSLT compiler to know in advance what type of value will be supplied, because it means that it can generate tighter code that doesn't have to deal with as many runtime possibilities. You don't have to declare the types of parameters, and if you don't, then any type of value will be accepted—but I would recommend as good programming practice always to declare the types. I certainly find that it catches many of my sillier programming mistakes.

Expressions

The syntax of expressions is defined in the XPath 2.0 Recommendation, and is described in detail in Chapters 7 through 11.

XPath expressions are used in a number of contexts in an XSLT stylesheet. They are used as attribute values for many XSLT elements, for example:

In this example
$x
and
$y
are references to variables, and the operators
+
and
*
have their usual meanings of addition and multiplication.

Many XPath expressions, like this one, follow a syntax that is similar to other programming languages. The one that stands out, however, and the one that gave XPath its name, is the
path expression
.

A path expression defines a navigation path through the document tree. Starting at a defined origin, usually either the current node or the document node, it follows a sequence of steps in defined directions. At each stage the path can branch, so for example you can find all the attributes of all the children of the origin node. The result is always a sequence of nodes in a fixed order (known as document order) with no duplicates. It might be empty or contain only one node, but it is still treated as a sequence.