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

Although template rules are a characteristic feature of the XSLT language, we'll see that this is not the only way of writing a stylesheet. In Chapter 17, I will describe four different design patterns for XSLT stylesheets, only one of which makes extensive use of template rules. In fact, the
Hello
World
stylesheet I presented earlier in this chapter doesn't make any real use of template rules; it fits into the design pattern I call
fill-in-the-blanks
, because the stylesheet essentially contains the fixed part of the output with embedded instructions saying where to get the data to put in the variable parts.

Types Based on XML Schema

I have described three characteristics of the XSLT language (the use of XML syntax, the principle of no side-effects, and the rule-based processing model) that were essential features of XSLT 1.0 and that have been retained essentially unchanged in XSLT 2.0. The fourth characteristic is new in XSLT 2.0, and creates a fundamental change in the nature of XSLT as a language. This is the adoption of a type system based on XML Schema.

There are two aspects to the type system of any programming language. The first is the set of types that are supported (for example, integers, strings, lists, tuples), together with the mechanisms for creating user-defined types. The second aspect is the rules that the language enforces to ensure type-correctness.

XSLT 1.0 had a very small set of types (integers, booleans, strings, node-sets, and result tree fragments), and the rules it applied were what is often called “weak typing”: this means that the processor would always attempt to convert the value supplied in an expression or function call to the type that was required in that context. This makes for a very happy-go-lucky environment: if you supply an integer where a string is expected, or vice versa, nothing will break.

XSLT 2.0 has changed both aspects of the type system. There is now a much richer set of types available (and this set is user-extensible), and the rules for type checking are stricter.

We will look at the implications of this in greater detail in Chapters 4 and 5.

A Two-Language System: XSLT and XPath

The final characteristic of XSLT that I want to explore is its use of XPath as an embedded sublanguage. This is not unlike the way SQL is often embedded in other languages, and it is done for the same reason—it allows XPath to be used in many different contexts.

The fact that XPath was designed to be embedded in other language has some specific consequences:

• An embedded language does not need to have every conceivable piece of functionality. In the language of computer science, it does not need to be computationally complete. In more practical terms, it can be restricted to being able to access variables but not to declare them, to call functions but not to define them, to navigate around nodes in a tree but not to create new nodes.
  
• An embedded language can depend on a context established by the host language in which it is embedded. If an embedded language is to be well integrated with a host language, then they should share information so that the user does not need to declare things twice, once for each language. The information that XPath shares with its host language is called the context. This can be divided into information that's available at compile time (the static context), and information that's not available until runtime (the dynamic context). Both aspects of the XPath context are described in Chapter 7 of this book.
  
• An embedded language can be called by its host language, but cannot make calls in the other direction. XSLT can invoke XPath, but not the other way around. This means that there is incomplete composability of expressions when the XSLT language is considered as a whole. However, XPath can invoke XSLTindirectly by means of function calls. Some functionality, notable conditional and iteration constructs, are duplicated in XSLT and XPath.
  

The syntax of XPath has some unusual features, which reflect the fact that it amalgamates ideas from a number of different sources. One can identify three different syntactic styles within XPath expressions:

• Conventional programming expressions:
  This allows the same kind of expressions, infix operators, and function calls as many other programming languages; an example is an expression such as
  $x + 1 = round($y) mod 3
  . Such expressions trace their roots via programming languages such as Algol and Fortran back to the notations of elementary mathematics.
  
• Path expressions:
  These perform hierarchic selection of a node within a tree, an example is
  /a/b//c
  . These expressions can be seen as a generalization of the syntax used by operating systems to identify files within a hierarchic filestore.
  
• Predicate logic:
  This includes the
  for
  ,
  some
  and
  every
  expressions, for example
  for $i in //item[@price > 30] return $i/@code
  . These expressions, which are new in XPath 2.0, derive from the tradition of database query languages (SQL, the object database language OQL, and precursors to XQuery), which can be seen as adaptations of the notation of mathematical symbolic logic.