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

Like other aspects of the static context, the way in which the in-scope functions are populated is defined by the host language. In most host languages, the function library is likely to include at least:

• The functions defined in the core library; that is, the functions listed in Chapter 13 of this book.
  
• A constructor function corresponding to each atomic type in the in-scope schema definitions. These functions are used to construct an instance of the corresponding atomic type; for example, the function
  xs:date(‘2004-06-01’)
  can be used to construct a date.
  

However, if a host language wanted to restrict the function library, it could choose to do so. For example, a host language might choose to support the whole function library with the exception of the
doc()
and
collection()
functions.

In XSLT, the in-scope functions include the two categories above, together with:

• A number of standard functions defined within the XSLT specification; for example,
  format-number()
  ,
  format-date()
  , and
  generate-id()
  . These are described along with the XPath functions in Chapter 13.
  
• User-defined functions written in the stylesheet using the
  
  declaration.
  
• Extension functions; for example, functions written as Java methods. The way in which extension functions are made available in the static context depends on the implementation. For example, XSLT processors written in Java generally provide an implicit binding to Java methods, in which the namespace URI of the function identifies a Java class name, and the local name identifies the method name within a class. In such cases the set of in-scope functions for the XPath processor effectively includes every public method in every class on the Java classpath. Other XSLT processors require an explicit binding of extension functions in the stylesheet, for example, through a vendor-defined declaration such as
  
  . In these cases, the functions added to the static context are those that are explicitly declared. (Extension functions are fully described in Chapter 16).
  

In principle, it's a static error if the XPath expression contains a call on a function that isn't present in the static context. However, this rule doesn't apply when XSLT backward-compability mode is in effect. This is to allow you to write conditional code that calls different extension functions depending on which XSLT processor you are using. Under these circumstances, the error won't actually be reported until the function call is executed at runtime.

As we saw above, function names contain a namespace URI and a local name. In an actual function call, the function name is written using an optional namespace prefix and a local name. If the prefix is absent, then the function is assumed to belong to the default namespace for functions, which we described earlier in this chapter on page 556. Usually (and always in XSLT), the default namespace for functions will be the namespace for the core function library, that is,
http://www.w3.org/2005/xpath-functions
. The XPath specification allows any namespace URI to be chosen as the default, but the host language doesn't have to pass this flexibility on to the user.

If there is a default namespace for functions (and as we've seen, there usually will be), then it becomes impossible to refer to functions that aren't in any namespace, because there is no way of associating a namespace prefix with names in the null namespace. The practical consequence of this is that if you import a schema with no target namespace, you will not be able to call constructor functions for the atomic types defined in that schema. Instead, you will have to use the more verbose
cast as
syntax, which is described in Chapter 9. For example, if you have an atomic type called
percentage
, you will have to write
98
cast
as
percentage
rather than
percentage(98)
.

Although constructor functions are named after atomic types, they use the default namespace for functions, not the default namespace for elements and types. For example, if the default namespace for elements and types is
http://ns.acme.com/
, and there is an atomic type
part-number
defined in the schema for this namespace, then you will be able to refer to the type without using a prefix; for example,
“AXZ98532”
cast
as
part-number
. But when you use the constructor function, the default namespace for functions applies, so you will typically need to use a namespace prefix, in this case:
acme:part-number(“AXZ98532”)
.