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

There is another type hierarchy, which represents the types of XPath items. This type hierarchy is shown in
Figure 5-5
.

Figure 5-5

This reflects the structure we described at the start of the chapter: every item in an XPath sequence is either a node or an atomic value; there are seven kinds of node, and the atomic types are either the built-in atomic types defined in the XML Schema specification, or user-defined atomic types.

Comparing these two diagrams:

• Atomic types appear in both. Atomic types can be used either as annotations on nodes, or as the type of a freestanding XPath item.
  
• Complex types, list types, and union types appear on the first diagram, but not the second. These types can be used as node annotations, but you can never have a freestanding XPath item that belongs directly to one of these types.
  
• Node kinds appear on the second diagram only. You can have an item in an XPath sequence that is an element or a comment or a processing instruction, but these types never appear as type annotations on element or attribute nodes.
  

It's a little unfortunate that the boxes on both these diagrams are all referred to as types, when we are actually dealing with two different (but overlapping) categories: I call the first category
schema types
and the second category
item types
. The W3 C specification for functions and operators attempts to depict both of these categories on a single type hierarchy diagram, but in my view this is likely to confuse more people than it enlightens. Apart from anything else, when you do this you find that
xs:anyAtomicType
, which appears on both diagrams, has two different supertypes.

Item types and schema types are used in different ways in XPath:

• You can test whether an item
  $V
  belongs to a particular item type
  T
  by writing
  $V instance of T
  .
  
• You can test whether a node
  $N
  has a type annotation that is a particular schema type
  S
  by writing
  $N instance of attribute(*, S)
  or
  $N instance of element(*, S)
  .
  

Because atomic types such as
xs:integer
belong to both categories, they can be used in either of these two ways. But item types such as
comment()
can only be used in the first of these roles, while non-atomic schema types such as
xs:IDREFS
can only be used in the second role.

The Type Matching Rules

The purpose of a type system in a language, as we saw, is to define which operations are legitimate for which types of value. In this section we will examine the way that XPath defines these rules.

It's easiest to start with the rules for function calling. XPath expressions can call functions written in XSLT or XQuery, as well as the functions provided in the core function library that comes with the language. Each of these functions has a signature, which defines the types of each of the arguments expected by the function. The rules described in this section define whether or not a particular value can be used in a function call, given a particular type used in the function signature. It turns out that the rules are exactly the same as those for binding values to variables in XSLT (the “weak conversions” that we introduced in Chapter 3, page 81).

For example, the signature of the function
remove()
is given in Chapter 13 as follows:

This shows that the function expects two arguments. The names of the arguments are irrelevant: these names are purely for reference within the documentation, they are not used in an actual function call. The important thing here is the type expected for each argument.

The first argument has a type of
item()*
. There are two parts to this: the item type and the cardinality. The item type in this case is
item()
, which is the most general item type of all, and accepts any node or atomic value. The cardinality is
*
, which means that the argument can be a sequence containing zero, one or more items. Taken together, this means that the first argument of
remove()
can be any sequence whatsoever.