XSLT and XPath function reference in alphabetical order

(Excerpt from “XSLT 2.0 & XPath 2.0” by Frank Bongers, chapter 5, translated from German)

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z



Information on the runtime environment


XSLT 1.0

Return value:

A Boolean value depending on whether the requested instruction or extension instruction is available in the runtime environment or not.




Obligatory. The argument of the function is a xs:string string which has to be marked by string delimiters in case it is passed on as literal. The argument is interpreted as QName of the instruction to be tested for availability and has to correspond in its expanded form to the expanded QName of the instruction.

If the instruction designated thus is within the XLST namespace, it must be a valid XSLT instruction, otherwiese it is considered as extension instruction. If the QName has no prefix (null namespace), the function always returns false.

Purpose of use:

The element-available() function is used in order to query prior to the processing whether an extension instruction required in the stylesheet is supported in the currently available runtime environment (i.e. by the processing XSLT processor).

If the instruction is supported, the XLST processor returns the value true, otherwise false. The mere presence of a not supported instruction in a template does not cause an error a priori. In the case of an actually necessary evaluation, the XSLT processor shall use an existing and alternative xsl:fallback element and execute its template content.

Since an instruction, irrespective of whether it is originated from XSLT or it is an extension instruction, has always to be within a namespace, in principle false is returned, provided that the string passed on has no prefix portion during its interpretation as QName and, consequently, has a null namespace.

Only applicable to instructions:
The element-available() function refers to XSLT instructions and not to XSLT declarations (top-level elements). If the function is applied to declarations, it may indeed also return false depending on the used XSLT processor, although the respective declaration is supported (as is the case, for instance, with Saxon). In pratice, no problems will arise from this circumstance.

Example 1 – test on a new XSLT instruction:

<xsl:if test="element-available('xsl:new-instruction')"> 
   <xsl:new-instruction>Hello World!</xsl:new-instruction> 

A XSLT instruction is shielded by a xsl:if test and only then executed if it is supported by the processor. When testing, the use of the required string delimiters around the instruction name is to be taken into account.

Example 2 – test on an extension instruction:

  <xsl:when test="element-available('ext:uppercase')">
    <p>ext:uppercase is supported.</p>
    <p>ext:uppercase is not supported.</p>

Here, the element-available function is used as an argument of a xsl:when test and accordingly various template sections are activated.

Example 3 – test on the non-existence of an extension instruction:

<xsl:if test="not(element-available('sql:connect'))">
   <xsl:message>sql:connect is not available</xsl:message>

In this example, a test is made on whether the (Saxon) SQL extension is supported, and a message is outputted with xsl:message if this is not the case.

Function definition:

XSLT 1.0:

element-available('instructionName') => boolean

XSLT 2.0:

element-available($instructionName as xs:string) as xs:boolean


<< back next >>




Copyright © Galileo Press, Bonn 2008
Printing of the online version is permitted exclusively for private use. Otherwise this chapter from the book "XSLT 2.0 & XPath 2.0" is subject to the same provisions as those applicable for the hardcover edition: The work including all its components is protected by copyright. All rights reserved, including reproduction, translation, microfilming as well as storage and processing in electronic systems.

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Germany