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

For other kinds of name, for example attribute names and variable names, there is no default namespace. For these names, no prefix always means no namespace.

In-Scope Schema Definitions

This part of the static context represents the schema information that is available at the time an XPath expression is compiled. Technically, it consists of:

• A set of named top-level type definitions (simple and complex types)
  
• A set of named top-level element declarations
  
• A set of named top-level attribute declarations
  

Type definitions, element declarations, and attribute declarations are referred to collectively as schema components (there is apparently a good reason why types are “defined”, whereas elements and attributes are “declared”, but the explanation I was given was pretty tortuous).

The specifications don't say exactly what information can be extracted from these definitions; this is left to the implementation to sort out. In theory XPath itself, because it doesn't actually validate elements against the schema, doesn't need to know very much about them at all. All it needs to be able to do is to look at the type annotation on a node and decide whether the node is or is not an instance of a given type in the schema, which it can do by knowing the names of the types and the type hierarchy. In practice of course, XPath implementations can use a lot more information than this for optimization purposes.

XPath itself isn't concerned with where these definitions come from. It's the job of the host language to decide which types are made available in the context. In practice there's a minimum set of types that must be available, because the XPath functions and operators need them: this set corresponds roughly to the set of types that a basic XSLT processor will make available, but it's XSLT that defines this set, not XPath itself.

In XSLT, the schema components provided in the static context include:

• Some or all of the built-in types of XML Schema. In the case of a schema-aware processor, this includes all the built-in types, but in the case of a basic (non-schema-aware) processor it is a smaller subset (see page 548).
  
• Schema components from schemas imported using the
  
  declaration in the stylesheet. This declaration can only be used if the XSLT processor is schema-aware.
  
• Other implementation-defined types needed to support vendor extensions; for example, the ability to call external Java methods.
  

For example, if you want to reference components from the OpenGIS schema for geographical coordinate systems, you might write in your stylesheet:

You will probably want to bind a prefix to this namespace:

You can then use XPath expressions that reference components in this schema, for example:

A different host language, however, could make schema components available in a different way entirely. There is no obligation on the host language to put this under user control.

An XPath expression cannot make explicit reference to types (for example, in an
instance of
expression, described in Chapter 11) unless those types are present in the static context. This also applies to element declarations named in a
schema-element(N)
test, and to attribute declarations named in a
schema-attribute(N)
test. (These constructs are all defined in Chapter 11.) Elements and attributes that are named in the ordinary way within a path expression, however, do not need to have a declaration present in the static context.

The set of schema components that are present in the static context may be a subset of those available at runtime. This is an issue that caused the working groups a great deal of grief: what happens if the XPath expression calls the
doc()
function to load a document, and that document is validated using a schema (perhaps the schema named in its
xsi:schemaLocation
attribute) that wasn't supplied as part of the static context for the XPath expression? The problem arises when you write an XPath expression such as
doc(‘abc.xml’)/a/b instance of xs:integer
. To evaluate this, the XPath processor needs to look at the type annotation on the

element and determine whether this type is a subtype of
xs:integer
. How is it supposed to know?

In fact, it's not just expressions like this that need the type information. A simple comparison such as
if
(doc(‘abc.xml’)/a/b=$x)
then
…
uses the typed value of the

element, and to determine how to do the comparison, the processor needs to know the type.