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

The second argument has a type of
xs:integer
. There is no cardinality specified, which means that the default cardinality is used: the effect of this is that the sequence supplied as the argument value must contain exactly one item. The item type for this argument is
xs:integer
, which means that the supplied value must be an atomic value labeled as an
xs:integer
, or as a subtype of
xs:integer
(for example, it might be labeled as an
xs:positiveInteger
). Supplying any other value would lead to a type error, which might be reported either when the expression is compiled or when it is subsequently evaluated.

Actually, the type system is not quite as rigid as this. Instead of supplying an
xs:integer
for the second argument, you can also supply:

• An untyped atomic value, provided that it takes a form that can be converted to an integer
  
• A node, provided that the typed value of the node is either an
  xs:integer
  , or an untyped atomic value
  

However, you cannot supply a string (even a string that obviously contains an integer, such as
“17”
), and you cannot supply a value of a different numeric type, such as
xs:decimal
or
xs:double
. You can use an
xs:integer
where an
xs:double
is expected, but not the other way around.

When the function call expects an atomic value and the supplied value is a node, the system goes through a process called
atomization
to extract the typed value of the node. Atomization is applied to the supplied value (a sequence) to produce a derived value (the atomized sequence). The rules are:

• Any atomic value in the supplied sequence is added to the atomized sequence unchanged.
  
• For any node in the supplied sequence, the typed value is extracted, as described in Chapter 2 (see page 52). The typed value is in general a sequence of zero or more atomic values, and the values in this sequence are added to the atomized sequence. If the node has not been validated against a schema, these atomic values will be untyped (they will have the type label
  xs:untypedAtomic
  ); if they have been validated, they are likely to have some other type such as
  xs:integer
  or
  xs:date
  .
  
• For some kinds of node, extracting a typed value is not possible: specifically, this is true for elements that are labeled with a type that has complex element-only content. Supplying such a node where the function expects an atomic value is an error, and the XPath evaluation will fail.
  

The atomized sequence is then checked against the type given in the function signature. The cardinality of the sequence as a whole must match the cardinality constraints given in the function signature, and each item in the sequence must match the item type given.

The detailed syntax for describing the allowed type of each function argument is given in Chapter 11, where it is referred to as a sequence type descriptor. The detailed rules for deciding whether a particular value is allowed as an argument to a function call, and the way it is converted to the required type when necessary, are given in Chapter 7, in the section describing function calls on page 544.

Function calls are not the only place where a value needs to be checked against a required type. We've already seen that the same rules apply to XSLT variables and parameters. Many of the XPath operators, such as
+
,
-
, and
|
, also have rules saying what type of operands are acceptable. These rules are based on the rules for function calls, but they are slightly different because XPath allows operators to be polymorphic: that is, the same operator can mean different things depending on the types of the arguments supplied. This is not currently allowed for function calls. For each operator, the rules are therefore slightly different, and they are described in this book in the section dealing with each operator. The non-trivial examples are the
=
family of operators and the arithmetic operators, which are all described in Chapter 8.