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

The XPath 2.0 Recommendation distinguishes static type checking from dynamic type checking. A product that offers static type checking is pessimistic: it assumes that if things can go wrong, they will go wrong. For example, if the operand of
+
is known at compile time to be either a string or an integer, the compiler will report a failure, because the pessimistic assumption is that sooner or later, the actual value of the operand will turn out to be a string. Remember that XPath 2.0 can be used in many environments other than XSLT. The XSLT specification largely assumes that implementors won't choose to provide pessimistic static typing, though it's not entirely ruled out.

In XSLT I think you are more likely to encounter a half-way house, which I will call
optimistic
static type checking. Here, you will only get an error message at compile time if the system knows that an expression cannot possibly succeed. An example of such an expression is:

Here the operand on the left will always be an
xs:date
, and the operand on the right will always be an
xs:string
. Comparison of a date to a string can never succeed, so even an optimistic type checker can report the error at compile time. To correct the error, you need to write:

It's worth pointing out that neither static nor dynamic type checking can catch all errors. Going back to my knight's tour where two parameters to a function call were coded in the wrong order, the error was only caught because the two arguments had different types. If both arguments had had a type of
xs:integer
, say, the function call would have succeeded, and the query would have gone on to produce garbage output.

A great deal depends in practice on how carefully you specify your types. Specifying the types of function parameters and of variables is done at the XSLT level, and it is this type information that forms the basis of the type checking performed by the XPath processor. If you choose not to specify any types at all, this is rather like declaring every Java variable or function with the generic type
Object
: you will get no compile time errors but an awful lot of runtime errors. I find that it's good programming discipline always to declare the types of variables and of function arguments. However, it's generally best to avoid over-constraining them. It can be tempting to declare types such as
xs:positiveInteger
, rather than
xs:integer
, if the value will always be positive; but as we've seen, this doesn't just constrain the value to be positive; it means that it actually has to be labeled as an
xs:positiveInteger
. The value represented by the XPath numeric literal
3
is an
xs:integer
, but it is not an
xs:positiveInteger
, because it has the wrong type label. So I tend to steer clear of using such types, because they create too much inconvenience.

Summary

The type system is probably the most innovative and the most controversial aspect of XPath 2.0, and it is very different in concept from the type system of XPath 1.0. We started this chapter with a brief rationale for introducing a type system based on XML Schema, and we ended the chapter with a discussion of the different forms of type checking that XPath 2.0 processor can apply, and some hints and tips to enable you to choose the right options.

In between, we looked in detail at each of the built-in atomic types defined in the XML Schema specification. We then saw how the type hierarchy in XML Schema relates to the type hierarchy in the XPath data model: they are strongly related, but they are not the same thing.

We also outlined how the type checking rules operate when calling an XPath function.

We're now moving into the section of the book that provides detailed reference information for each construct in the XSLT and XPath languages. Until now you may well have been reading the book sequentially. The next chapter, however, is a long one—it contains a detailed alphabetical reference of all the XSLT elements you can use in a stylesheet—and I would suggest that rather than reading it from start to finish, you dip into the sections describing the specific instructions that you need to understand.

Part II

XSLT and XPath Reference

Chapter 6

XSLT Elements

This chapter provides an alphabetical list of reference entries, one for each of the XSLT elements. Each entry gives:

• A short description of the purpose of the element
  
• Changes in 2.0
  : A quick summary of changes to this element since XSLT 1.0
  
• Format
  : A pro forma summary of the format, defining where the element may appear in the stylesheet, what its permitted attributes are, and what its content (child elements) may be
  
• Effect
  : A definition of the formal rules defining how this element behaves
  
• Usage
  : A section giving usage advice on how to exploit this XSLT element
  
• Examples
  : Coding examples of the element, showing the context in which it might be used (where appropriate, the
  Usage
  and
  Examples
  sections are merged into one)
  
• See also
  : Cross-references to other related constructs
  

The
Format
section for each element includes a syntax skeleton designed to provide a quick reminder of the names and types of the attributes and any constraints on the context. The format of this is designed to be intuitive: it only gives a summary of the rules, because you will find these in full in the
Position
,
Attributes
, and
Content
sections that follow.

There are a number of specialized terms used in this chapter, and it is worth becoming familiar with them before you get in too deeply. There are fuller explanations in Chapters 2 and 3, and the descriptions in the following table are really intended just as a quick memory-jogger.

Term	Description
attribute value template	An attribute whose value may contain expressions nested with curly braces, for example url=“../{$href}” . The term template here has nothing to do with any other kind of template in XSLT. Embedded expressions may only be used in an attribute value (or are only recognized as such) if the attribute is one that is explicitly designated as an attribute value template. Attribute value templates are described in more detail in Chapter 3, page 122.
document order	An ordering of the nodes in the source tree that corresponds to the order in which the corresponding items appeared in the source XML document: an element precedes its children, and the children are ordered as they appeared in the source.
expression	Many XSLT elements have attributes whose value is an expression . This always means an XPath expression: a full definition of XPath Expressions is given in Chapters 7 to 11, and a summary is given in Appendix A. An expression returns a value, which may be any sequence of items (nodes, atomic values, or a mixture of the two). These types are described fully in Chapter 2.
Extension instructions	Any element used in a sequence: specifically, an XSLT instruction, a literal result element, or an extension element. The element is an instruction, but isn't, because appears in a sequence constructor and doesn't. Extension instructions are described in Chapter 3, page 111.
literal result element	An element in the stylesheet, used in a sequence constructor , which is copied to the output document: for example (if you are generating HTML) or	. Literal result elements are described in Chapter 3, page 112.
pattern	Some XSLT elements have attributes whose value must be a pattern. The syntax of patterns is defined in Chapter 12. A pattern is a test that can be applied to nodes to see if they match. For example, the pattern title matches all