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

What lies behind these rules is that XPath 1.0 was a weakly typed language, in which the arguments of function calls and operators were implicitly converted to the required type. XPath 2.0 has a much richer type system, in which such implicit conversion would often give unexpected results. So with XPath 2.0, you have to do the conversions you want explicitly. But this creates a backward-compatibility problem. The rules given above are designed to minimize this problem by catering for all the cases that could actually arise with a 1.0 expression. The reason that strings and numbers are treated differently from other types is that they are the only atomic types that were supported in XPath 1.0—except for booleans. And in the case of booleans, weak typing continues to apply in XPath 2.0: every value can be converted to a boolean when it is used in a context such as the condition of an
if
expression, by taking its
effective boolean value
. The rules for this are described on page 551.

The following table illustrates some expressions whose results differ when running in backward- compatibility mode.

In-Scope Namespaces

Many XPath expressions contain prefixed QNames. The names of elements and attributes can be prefixed, as can the names of variables, functions, and types. A prefix in such a name means nothing by itself: to know what type the name
xs:integer
refers to, you have to know what namespace URI is bound to the prefix
xs
. It isn't possible to define the binding of a prefix to a namespace URI within the XPath expression itself, so instead it has to be part of the context. It's part of the static context so that the XPath processor can work out at compile time what all names appearing in the expression are actually referring to.

This part of the static context is modeled as a set of (prefix, URI) pairs. No prefix may appear more than once. It's an error if the XPath expression contains a QName whose prefix isn't present in this list.

In XSLT, because a stylesheet is an XML document, the in-scope namespaces for an XPath expression are defined by writing namespace declarations such as
xmlns:xs=“http://www.w3.org/2001/XMLSchema”
in a containing element (often, but not necessarily, the

element). The namespace prefixes you can use within an XPath expression are precisely those that you could use in an element name or attribute name appearing in the same place in the stylesheet.

Each stylesheet module has its own static context, so a global variable declared in one module as:

might be referenced in another module as:

For other host languages, a different way of establishing the namespace context might be used. XQuery, for example has its own syntax for declaring namespaces, as does XPointer. In XQuery some namespaces (such as the XML Schema namespace) are hardwired, and others can be declared in the query prolog using syntax such as:

In XPointer the syntax is:

When XPath is used from a programming language such as Java, there will generally be some method in the API that allows a namespace to be declared. In some APIs it is possible to declare namespaces implicitly by nominating a node in a source document, indicating that all the namespaces that are in scope for that node should be considered to be in scope for the XPath expression.

Default Namespaces

When a QName that has no namespace prefix is used, default namespaces come into play.

In XPath 1.0, the rule was simple: no prefix means no namespace. That is, unprefixed names always referred to objects whose namespace URI was null. In XPath 2.0 there is more flexibility. The static context potentially contains two defaults, for use with different kinds of names:

• The default namespace for elements and types, as the name implies, is used to qualify any name within the XPath expression that is recognized as an element name or a type name. In path expressions, it is always possible to distinguish element names by means of the axis on which they appear: if the axis is the attribute or namespace axis, then unprefixed names are considered to be in no namespace, whereas on any other axis, the namespace URI for an unprefixed name is taken from this default. The default is also used for element names appearing in a test such as
  element(invoice,
  *)
  , and for the names of types, in constructs such as
  attribute (*,
  part-number)
  .
  

  In XSLT 2.0, the default namespace for elements and types can be set or unset using the
  [xsl:]xpath-default-namespace
  attribute on any element in the stylesheet. This is described on page 480.
  

• The default namespace for functions is used to qualify unprefixed names used in function calls, for example
  f()
  . In XSLT this is always the standard namespace
  http://www.w3.org/2005/xpath-functions
  , which contains the functions listed in Chapter 13. Other host languages or APIs might define a different default.