XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (310 page)
Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
The XPath processor is required to check that the arguments supplied in the function call are of the right type, and it can also apply a very limited number of conversions to make them the right type. These rules are referred to as the
function conversion rules
. The rules are as follows:
1.
First, at compile time, the name of the function and the number of arguments are used to locate the signature of the function to be called. An error occurs if no suitable function can be located. Once the signature has been located, the processor may do some compile-time checking of arguments, but the only guarantee is that each argument in the function call will be checked against the declared type of the corresponding parameter in the signature at runtime, using the rules below.
2.
Each supplied argument is evaluated, to produce a value. This in general is a sequence that may contain atomic values, nodes, or a mixture of the two. (Note, however, that the processor isn't obliged to evaluate an argument that isn't used—this means that errors may go undetected.)
3.
If the required item type is
xs:anyAtomicType
or a subtype of this (that is, if the function expects atomic values for this argument, rather than nodes), then the following steps are carried out:
- The supplied sequence is atomized. Atomization replaces each node in the supplied sequence by its typed value (which may itself be a sequence) and leaves any atomic values in the sequence unchanged.
- If any of the values in the atomized sequence are of type
xs:untypedAtomic
(which will normally be the case when the values are extracted from elements and attributes that have not been validated against any schema), then the system attempts to convert them to the required type by casting. The rules showing what casts are possible are given in Chapter 11, but they essentially follow the rules defined in XML Schema—if the required type is
xs:date
, for example, then the
xs:untypedAtomic
value must have the form of a valid lexical
xs:date
value. If the cast isn't possible, the error is fatal. - If the required type is a numeric type (
xs:double
,
xs:float
,
xs:decimal
, or a type derived from any of these by restricting the allowed set of values), and if the supplied value is also numeric, then type promotion is attempted. For example, it is acceptable to supply an
xs:integer
value where an
xs:double
is expected. Numeric type promotion is described in detail in Chapter 8, because it plays an important role for arithmetic operators. - If the required type is
xs:string
and the supplied value is an instance of
xs:anyURI
, the URI is converted to a string. In effect, XPath treats
xs:anyURI
as a subtype of
xs:string
even though XML Schema does not define it that way.
4.
At this stage, a final check is made that the argument value is now a valid instance of the required type. For this to be true, each item in the sequence must be an instance of the required item type, and the number of items in the sequence must match the required cardinality. The detailed rules are the same as those for the
instance of
operator, which is described in Chapter 11. If the value doesn't conform as required, a type error is reported.
5.
If all is well, the function is called, and the result of the function call expression (as you would expect) is the value returned by the function, which will always conform to the type given in the function signature.
Changes in XPath 2.0
The rules given in the previous section impose much stricter type checking than XPath 1.0, which always attempted to convert the supplied arguments to the required type. XPath 2.0 effectively retains this behavior in two cases: firstly, when the value you supply is a node in a document that has not been schema-validated, and secondly, when you run in backward-compatibility mode, which in XSLT is activated by settingversion=“1.0”in the
So there are cases where function calls would have succeeded in XPath 1.0, but will fail under 2.0. An example is an expression such asstring-length(position())=2. The argument to the
string-length()
function must be of type
xs:string
, but the result returned by the
position()
function is of type
xs:integer
. XPath 1.0 would cheerfully convert the integer to a string, but XPath 2.0 is stricter—if you intend a conversion to take place, you must invoke it explicitly, for example by calling the
string()
function.
Backward-compatibility mode changes the function calling rules by adding an extra rule before rule 3 in the list above. This rule is in two parts:
- If the required cardinality of the parameter is zero or one (that is, if the parameter doesn't permit a sequence of more than one item), then all items in the supplied value after the first are discarded.
- If the required item type is a string or number type, then the supplied value is converted to a string or number using the
string()
or
number()
function as appropriate.
These rules apply only where the required type of the parameter fits into the XPath 1.0 type system. For example, if the required type is
xs:date
, no extra conversions are performed. More specifically, the first rule (which discards all but the first item in a sequence) applies only where the required item type isitem(),node(),
xs:string
, or a numeric type such as
xs:double
. The second rule applies only if the required item type is
xs:string
or a numeric type.