20 Additional Functions

This section describes XSLT-specific additions to the XPath function library. Some of these additional functions also make use of information specified by declarations in the stylesheet; this section also describes these declarations.

20.1 fn:document

Summary

Provides access to XML documents identified by a URI.

Signatures
fn:document($uri-sequence as item()*) as node()*
fn:document( $uri-sequence  as item()*,
$base-node  as node()) as node()*
Properties

The one-argument form of this function is deterministicFO30, focus-independentFO30, and context-dependentFO30. It depends on static base URI.

The two-argument form of this function is deterministicFO30, focus-independentFO30, and context-independentFO30.

Rules

The document function allows access to XML documents identified by a URI.

The first argument contains a sequence of URI references. The second argument, if present, is a node whose base URI is used to resolve any relative URI references contained in the first argument.

A sequence of absolute URI references is obtained as follows.

  • For an item in $uri-sequence that is an instance of xs:string, xs:anyURI, or xs:untypedAtomic, the value is cast to xs:anyURI. If the resulting URI reference is an absolute URI reference then it is used as is. If it is a relative URI reference, then it is resolved as follows:

    1. If $base-node is supplied, then it is resolved against the base URI of $base-node.

    2. Otherwise it is resolved against the static base URI from the static context of the expression containing the call to the document function. In cases where the source code of the stylesheet is available at execution time, this will typically be the location of the relevant stylesheet module.

  • For an item in $uri-sequence that is a node, the node is atomized. The result must be a sequence whose items are all instances of xs:string, xs:anyURI, or xs:untypedAtomic. Each of these values is cast to xs:anyURI, and if the resulting URI reference is an absolute URI reference then it is used as is. If it is a relative URI reference, then it is resolved against the base URI of $base-node if supplied, or against the base URI of the node that contained it otherwise.

  • A relative URI is resolved against a base URI using the rules of the resolve-uriFO30 function. A dynamic error occurs (see below) if no base URI is available.

  • If $uri-sequence (after atomizing any nodes) contains an item other than an atomic value of type xs:string, xs:anyURI, or xs:untypedAtomic then a type error is raised [ERR XPTY0004] XP30.

Each of these absolute URI references is then processed as follows. Any fragment identifier that is present in the URI reference is removed, and the resulting absolute URI is cast to a string and then passed to the docFO30 function defined in [Functions and Operators 3.0]. This returns a document node. If an error occurs during evaluation of the docFO30 function, the processor may either signal this error in the normal way, or may recover by ignoring the failure, in which case the failing URI will not contribute any nodes to the result of the document function.

If the URI reference contained no fragment identifier, then this document node is included in the sequence of nodes returned by the document function.

If the URI reference contained a fragment identifier, then the fragment identifier is interpreted according to the rules for the media type of the resource representation identified by the URI, and is used to select zero or more nodes that are descendant-or-self nodes of the returned document node. As described in 2.3 Initiating a Transformation, the media type is available as part of the evaluation context for a transformation.

The sequence of nodes returned by the function is in document order, with no duplicates. This order has no necessary relationship to the order in which URIs were supplied in the $uri-sequence argument.

Error Conditions

[ERR XTDE1160] When a URI reference contains a fragment identifier, it is a dynamic error if the media type is not one that is recognized by the processor, or if the fragment identifier does not conform to the rules for fragment identifiers for that media type, or if the fragment identifier selects something other than a sequence of nodes (for example, if it selects a range of characters within a text node).

A processor may provide an option which, if selected, causes the processor instead of signaling this error, to ignore the fragment identifier and return the document node.

The set of media types recognized by a processor is implementation-defined.

[ERR XTDE1162] When a URI reference is a relative reference, it is a dynamic error if no base URI is available to resolve the relative reference. This can arise for example when the URI is contained in a node that has no base URI (for example a parentless text node), or when the second argument to the function is a node that has no base URI, or when the base URI from the static context is undefined.

Notes

One effect of these rules is that in an interpreted environment where the source code of the stylesheet is available and its base URI is known, then unless XML entities or xml:base are used, the expression document("") refers to the document node of the containing stylesheet module (the definitive rules are in [RFC3986]). The XML resource containing the stylesheet module is then processed exactly as if it were any other XML document, for example there is no special recognition of xsl:text elements, and no special treatment of comments and processing instructions.

The XPath rules for function calling ensure that it is a type error if the supplied value of the second argument is anything other than a single node. If XPath 1.0 compatibility mode is enabled, then a sequence of nodes may be supplied, and the first node in the sequence will be used.

20.2 Keys

Keys provide a way to work with documents that contain an implicit cross-reference structure. They make it easier to locate the nodes within a document that have a given value for a given attribute or child element, and they provide a hint to the implementation that certain access paths in the document need to be efficient.

20.2.1 The xsl:key Declaration

<!-- Category: declaration -->
<xsl:key
  name = eqname
  match = pattern
  use? = expression
  composite? = boolean
  collation? = uri >
  <!-- Content: sequence-constructor -->
</xsl:key>

The xsl:key declaration is used to declare keys. The name attribute specifies the name of the key. The value of the name attribute is an EQName, which is expanded as described in 5.1.1 Qualified Names. The match attribute is a Pattern; an xsl:key element applies to all nodes that match the pattern specified in the match attribute.

[Definition: A key is defined as a set of xsl:key declarations in the same package that share the same name.]

The key name is scoped to the containing package, and is available for use in calls to the key function within that package.

The value of the key may be specified either using the use attribute or by means of the contained sequence constructor.

[ERR XTSE1205] It is a static error if an xsl:key declaration has a use attribute and has non-empty content, or if it has empty content and no use attribute.

If the use attribute is present, its value is an expression specifying the values of the key. The expression will be evaluated with a singleton focus based on the node that matches the pattern. The result of evaluating the expression is atomized.

Similarly, if a sequence constructor is present, it is used to determine the values of the key. The sequence constructor will be evaluated with the node that matches the pattern as the context node. The result of evaluating the sequence constructor is atomized.

[Definition: The expression in the use attribute and the sequence constructor within an xsl:key declaration are referred to collectively as the key specifier. The key specifier determines the values that may be used to find a node using this key.]

When evaluation of the key specifier results in a sequence (after atomization) containing more than one atomic value, the effect depends on the value of the composite attribute:

  • When the attribute is absent or has the value no, each atomic value in the sequence acts as an individual key. For example, if match="book" use="author" composite="no" is specified, then a book element may be located using the value of any author element.

  • When the attribute is present and has the value yes, the sequence of atomic values is treated as a composite key that must be matched in its entirety. For example, if match="book" use="author" composite="yes" is specified, then a book element may be located using the value of all its author elements, supplied in the correct order.

If there are several xsl:key declarations in the same package with the same key name, then they must all have the same effective value for their composite attribute. The effective value is the actual value of the attribute if present, or "no" if the attribute is absent.

Note:

There is no requirement that all the values of a key should have the same type.

The presence of an xsl:key declaration makes it easy to find a node that matches the match pattern if the values of the key specifier (when applied to that node) are known. It also provides a hint to the implementation that access to the nodes by means of these values needs to be efficient (many implementations are likely to construct an index or hash table to achieve this).

Note:

An xsl:key declaration is not bound to a specific source document. The source document to which it applies is determined only when the key function is used to locate nodes using the key. Keys can be used to locate nodes within any source document (including temporary trees), but each use of the key function searches one document only.

Keys can only be used to search within a tree that is rooted at a document node.

The optional collation attribute is used only when deciding whether two strings are equal for the purposes of key matching. Specifically, two key values $a and $b are considered equal if the result of the function call deep-equal($a, $b, $collation) is true. The effective collation for an xsl:key declaration is the collation specified in its collation attribute if present, resolved against the base URI of the xsl:key element, or the default collation that is in scope for the xsl:key declaration otherwise; the effective collation must be the same for all the xsl:key declarations making up a key.

[ERR XTSE1210] It is a static error if the xsl:key declaration has a collation attribute whose value (after resolving against the base URI) is not a URI recognized by the implementation as referring to a collation.

[ERR XTSE1220] It is a static error if there are several xsl:key declarations in the same package with the same key name and different effective collations. Two collations are the same if their URIs are equal under the rules for comparing xs:anyURI values, or if the implementation can determine that they are different URIs referring to the same collation.

[ERR XTSE1222] It is a static error if there are several xsl:key declarations in a package with the same key name and different effective values for the composite attribute.

It is possible to have:

  • multiple xsl:key declarations with the same name;

  • a node that matches the match patterns of several different xsl:key declarations, whether these have the same key name or different key names;

  • a node that returns more than one value from its key specifier (which can be treated either as separate individual key values, or as a single composite key value);

  • a key value that identifies more than one node (the key values for different nodes do not need to be unique).

An xsl:key declaration with higher import precedence does not override another of lower import precedence; all the xsl:key declarations in the stylesheet are effective regardless of their import precedence.

20.2.2 fn:key

Summary

Returns the nodes that match a supplied key value.

Signatures
fn:key( $key-name  as xs:string,
$key-value  as xs:anyAtomicType*) as node()*
fn:key( $key-name  as xs:string,
$key-value  as xs:anyAtomicType*,
$top  as node()) as node()*
Properties

The two-argument form of this function is deterministicFO30, focus-dependentFO30, and context-dependentFO30.

The three-argument form of this function is deterministicFO30, focus-independentFO30, and context-dependentFO30.

Rules

The key function does for keys what the element-with-idFO30 function does for IDs.

The $key-name argument specifies the name of the key. The value of the argument must be a string containing an EQName. If it is a lexical QName, then it is expanded as described in 5.1.1 Qualified Names (no prefix means no namespace).

The $key-value argument to the key function is considered as a sequence. The effect depends on the value of the composite attribute of the corresponding xsl:key declaration.

  • If composite is no or absent, the set of requested key values is formed by atomizing the supplied value of the argument, using the standard function conversion rules. Each of the resulting atomic values is considered as a requested key value. The result of the function is a sequence of nodes, in document order and with duplicates removed, comprising those nodes in the selected subtree (see below) that are matched by an xsl:key declaration whose name is the same as the supplied key name, where the result of evaluating the key specifier contains a value that is equal to one of these requested key values, under the rules appropriate to the XPath eq operator for the two values in question, using the collation attributes of the xsl:key declaration when comparing strings. No error is reported if two values are encountered that are not comparable; they are regarded for the purposes of this function as being not equal.

    If the second argument is an empty sequence, the result of the function will be an empty sequence.

  • If composite is yes, the requested key value is the sequence formed by atomizing the supplied value of the argument, using the standard function conversion rules. The result of the function is a sequence of nodes, in document order and with duplicates removed, comprising those nodes in the selected subtree (see below) that are matched by an xsl:key declaration whose name is the same as the supplied key name, where the result of evaluating the key specifier is deep-equal to the requested key value, under the rules appropriate to the deep-equalFO30 function applied to the two values in question, using the collation attributes of the xsl:key declaration when comparing strings. Note that the deep-equalFO30 function reports no error if two values are encountered that are not comparable; they are regarded for the purposes of this function as being not equal.

    If the second argument is an empty sequence, the result of the function will be the set of nodes having an empty sequence as the value of the key specifier.

Different rules apply when XSLT 1.0 compatible behavior is enabled.

A key (that is, a set of xsl:key declarations sharing the same key name) is processed in backwards compatible mode if (a) at least one of the xsl:key elements in the definition of the key enables backwards compatible behavior, and (b) the effective value of the composite attribute is no.

When a key is processed in backwards compatible mode, then:

  • The result of evaluating the key specifier in any xsl:key declaration having this key name is converted after atomization to a sequence of strings, by applying a cast to each item in the sequence.

  • When the first argument to the key function specifies this key name, then the value of the second argument is converted after atomization to a sequence of strings, by applying a cast to each item in the sequence. The values are then compared as strings.

The third argument is used to identify the selected subtree. If the argument is present, the selected subtree is the set of nodes that have $top as an ancestor-or-self node. If the argument is omitted, the selected subtree is the document containing the context node. This means that the third argument effectively defaults to /.

The result of the key function can be described more specifically as follows. The result is a sequence containing every node $N that satisfies the following conditions:

  • $N/ancestor-or-self::node() intersect $top is non-empty. (If the third argument is omitted, $top defaults to /)

  • $N matches the pattern specified in the match attribute of an xsl:key declaration whose name attribute matches the name specified in the $key-name argument.

  • When composite="no", and the key specifier of that xsl:key declaration is evaluated with a singleton focus based on $N, the atomized value of the resulting sequence includes a value that compares equal to at least one item in the atomized value of the sequence supplied as $key-value, under the rules of the eq operator with the collation selected as described above.

    When composite="yes", and the key specifier of that xsl:key declaration is evaluated with a singleton focus based on $N, the atomized value of the resulting sequence compares equal to the atomized value of the sequence supplied as $key-value, under the rules of the deep-equalFO30 function with the collation selected as described above.

The sequence returned by the key function will be in document order, with duplicates (that is, nodes having the same identity) removed.

Error Conditions

[ERR XTDE1260] It is a dynamic error if the value is not a valid QName, or if there is no namespace declaration in scope for the prefix of the QName, or if the name obtained by expanding the QName is not the same as the expanded name of any xsl:key declaration in the containing package. If the processor is able to detect the error statically (for example, when the argument is supplied as a string literal), then the processor may optionally signal this as a static error.

[ERR XTDE1270] It is a dynamic error to call the key function with two arguments if there is no context node, or if the root of the tree containing the context node is not a document node; or to call the function with three arguments if the root of the tree containing the node supplied in the third argument is not a document node.

Notes

Untyped atomic values are converted to strings, not to the type of the other operand. This means, for example, that if the expression in the use attribute returns a date, supplying an untyped atomic value in the call to the key function will return an empty sequence.

Examples
Example: Using a Key to Follow Cross-References

Given a declaration

<xsl:key name="idkey" match="div" use="@id"/>

an expression key("idkey",@ref) will return the same nodes as id(@ref), assuming that the only ID attribute declared in the XML source document is:

<!ATTLIST div id ID #IMPLIED>

and that the ref attribute of the context node contains no whitespace.

 

Example: Using a Key to Generate Hyperlinks

Suppose a document describing a function library uses a prototype element to define functions

<prototype name="sqrt" return-type="xs:double">
  <arg type="xs:double"/>
</prototype>

and a function element to refer to function names

<function>sqrt</function>

Then the stylesheet could generate hyperlinks between the references and definitions as follows:

<xsl:key name="func" match="prototype" use="@name"/>

<xsl:template match="function">
<b>
  <a href="#{generate-id(key('func',.))}">
    <xsl:apply-templates/>
  </a>
</b>
</xsl:template>

<xsl:template match="prototype">
  <p>
    <a name="{generate-id()}">
      <b>Function: </b>
      ...
    </a>
  </p>
  </xsl:template>

When called with two arguments, the key function always returns nodes that are in the same document as the context node. To retrieve a node from any other document, it is necessary either to change the context node, or to supply a third argument.

Example: Using Keys to Reference other Documents

For example, suppose a document contains bibliographic references in the form <bibref>XSLT</bibref>, and there is a separate XML document bib.xml containing a bibliographic database with entries in the form:

<entry name="XSLT">...</entry>

Then the stylesheet could use the following to transform the bibref elements:

<xsl:key name="bib" match="entry" use="@name"/>

<xsl:template match="bibref">
  <xsl:variable name="name" select="."/>
  <xsl:apply-templates select="document('bib.xml')/key('bib',$name)"/>
</xsl:template>

Note:

This relies on the ability in XPath 2.0 to have a function call on the right-hand side of the / operator in a path expression.

The following code would also work:

<xsl:key name="bib" match="entry" use="@name"/>

<xsl:template match="bibref">
  <xsl:apply-templates select="key('bib', ., document('bib.xml'))"/>
</xsl:template>

 

Example: Using a Composite Key

This example uses a composite key consisting of first name and last name to locate employees in an employee file.

The key can be defined like this:

<xsl:key name="emp-name-key" 
         match="employee" 
         use="name/first, name/last" 
         composite="yes"/>                     
         

A particular employee can then be located using the function call:

key('emp-name-key', ('Tim', 'Berners-Lee'), doc('employees.xml'))

20.3 Keys and Streaming

Keys are not applicable to streamed documents.

This is ensured by the rules for the streamability of the key function (see 19.8.9 Classifying Calls to Built-In Functions). These rules make the operand usage of the third argument navigation, which has the consequence that when the key function is applied to a streamed input document, the call is roaming and free-ranging, which effectively makes the containing construct non-streamable.

20.4 Miscellaneous Additional Functions

20.4.1 fn:current

Summary

Returns the item that is the context item for the evaluation of the containing XPath expression

Signature
fn:current() as item()
Properties

This function is deterministicFO30, context-dependentFO30, and focus-dependentFO30.

Rules

The current function, used within an XPath expression, returns the item that was the context item at the point where the expression was invoked from the XSLT stylesheet. This is referred to as the current item. For an outermost expression (an expression not occurring within another expression), the current item is always the same as the context item. Thus,

<xsl:value-of select="current()"/>

means the same as

<xsl:value-of select="."/>

However, within square brackets, or on the right-hand side of the / operator, the current item is generally different from the context item.

If the current function is used within a pattern, its value is the item that is being matched against the pattern.

Error Conditions

[ERR XTDE1360] If the current function is evaluated within an expression that is evaluated when the context item is absent, a dynamic error occurs.

When the current is called by means of a dynamic function call (for example, current#0()), it is evaluated as if the context item is absent ([see ERR XTDE1360]).

Examples

The instruction:

<xsl:apply-templates select="//glossary/entry[@name=current()/@ref]"/>

will process all entry elements that have a glossary parent element and that have a name attribute with value equal to the value of the current item's ref attribute. This is different from

<xsl:apply-templates select="//glossary/entry[@name=./@ref]"/>

which means the same as

<xsl:apply-templates select="//glossary/entry[@name=@ref]"/>

and so would process all entry elements that have a glossary parent element and that have a name attribute and a ref attribute with the same value.

20.4.2 fn:unparsed-entity-uri

Summary

Returns the URI (system identifier) of an unparsed entity

Signatures
fn:unparsed-entity-uri($entity-name as xs:string) as xs:anyURI
fn:unparsed-entity-uri( $entity-name  as xs:string,
$doc  as node()) as xs:anyURI
Properties

This function is deterministicFO30, focus-dependentFO30, and context-dependentFO30.

Rules

Calling the single-argument form of this function has the same effect as calling the two-argument form with the context item as the second argument.

The two-argument unparsed-entity-uri function returns the URI of the unparsed entity whose name is given by the value of the $entity-name argument, in the document containing the node supplied as the value of the $doc argument. It returns the zero-length xs:anyURI if there is no such entity. This function maps to the dm:unparsed-entity-system-id accessor defined in [XDM 3.0].

Error Conditions

[ERR XTDE1370] It is a dynamic error if $node, or the context item if the second argument is omitted, is a node in a tree whose root is not a document node.

The following errors may be raised when $node is omitted:

Notes

The XDM accessor dm:unparsed-entity-system-id is defined to return an absolute URI, obtained by resolving the system identifier as written against the base URI of the document. If no base URI is available for the document, the unparsed-entity-uri function should return the system identifier as written, without any attempt to make it absolute.

XML permits more than one unparsed entity declaration with the same name to appear, and says that the first declaration is the one that should be used. This rule should be respected during construction of the data model; the data model instance should not contain more than one unparsed entity with the same name.

20.4.3 fn:unparsed-entity-public-id

Summary

Returns the public identifier of an unparsed entity

Signatures
fn:unparsed-entity-public-id($entity-name as xs:string) as xs:string
fn:unparsed-entity-public-id( $entity-name  as xs:string,
$doc  as node()) as xs:string
Properties

This function is deterministicFO30, focus-dependentFO30, and context-dependentFO30.

Rules

Calling the single-argument form of this function has the same effect as calling the two-argument form with the context item as the second argument.

The two-argument unparsed-entity-public-id function returns the public identifier of the unparsed entity whose name is given by the value of the $entity-name argument, in the document containing the node supplied as the value of the $doc argument. It returns the zero-length string if there is no such entity, or if the entity has no public identifier. This function maps to the dm:unparsed-entity-public-id accessor defined in [XDM 3.0].

Error Conditions

[ERR XTDE1380] It is a dynamic error if $node, or the context item if the second argument is omitted, is a node in a tree whose root is not a document node.

The following errors may be raised when $node is omitted:

Notes

XML permits more than one unparsed entity declaration with the same name to appear, and says that the first declaration is the one that should be used. This rule should be respected during construction of the data model; the data model instance should not contain more than one unparsed entity with the same name.

20.4.4 fn:system-property

Summary

Returns the value of a system property

Signature
fn:system-property($property-name as xs:string) as xs:string
Properties

This function is deterministicFO30, focus-independentFO30, and context-dependentFO30. It depends on namespaces.

Rules

The value of the $property-name argument must be a string containing an EQName. If it is a lexical QName with a prefix, then it is expanded into an expanded QName using the namespace declarations in the static context of the expression. If there is no prefix, the name is taken as being in no namespace.

The system-property function returns a string representing the value of the system property identified by the name. If there is no such system property, the zero-length string is returned.

Implementations must provide the following system properties, which are all in the XSLT namespace:

  • xsl:version, a number giving the version of XSLT implemented by the processor; for implementations conforming to the version of XSLT specified by this document, this is the string "3.0". The value will always be a string in the lexical space of the decimal datatype defined in XML Schema (see [XML Schema Part 2]). This allows the value to be converted to a number for the purpose of magnitude comparisons.

  • xsl:vendor, a string identifying the implementer of the processor

  • xsl:vendor-url, a string containing a URL identifying the implementer of the processor; typically this is the host page (home page) of the implementer's Web site.

  • xsl:product-name, a string containing the name of the implementation, as defined by the implementer. This should normally remain constant from one release of the product to the next. It should also be constant across platforms in cases where the same source code is used to produce compatible products for multiple execution platforms.

  • xsl:product-version, a string identifying the version of the implementation, as defined by the implementer. This should normally vary from one release of the product to the next, and at the discretion of the implementer it may also vary across different execution platforms.

  • xsl:is-schema-aware, returns the string "yes" in the case of a processor that claims conformance as a schema-aware XSLT processor, or "no" in the case of a basic XSLT processor.

  • xsl:supports-serialization, returns the string "yes" in the case of a processor that offers the serialization feature, or "no" otherwise.

  • xsl:supports-backwards-compatibility, returns the string "yes" in the case of a processor that offers the XSLT 1.0 compatibility feature, or "no" otherwise.

  • xsl:supports-namespace-axis, returns the string "yes" in the case of a processor that offers the XPath namespace axis even when not in backwards compatible mode, or "no" otherwise. Note that a processor that supports backwards compatible mode must support the namespace axis when in that mode, so this property is not relevant to that case.

  • xsl:supports-streaming, returns the string "yes" in the case of a processor that offers the streaming feature (see 27.5 Streaming Feature), or "no" otherwise.

  • xsl:supports-dynamic-evaluation, returns the string "yes" in the case of a processor that offers the dynamic evaluation feature (see 27.6 Dynamic Evaluation Feature), or "no" otherwise.

  • xsl:supports-higher-order-functions, returns the string "yes" in the case of a processor that offers the higher-order functions feature, or "no" otherwise.

  • xsl:xpath-version, a number giving the version of XPath implemented by the processor. The value will always be a string in the lexical space of the decimal datatype defined in XML Schema (see [XML Schema Part 2]). This allows the value to be converted to a number for the purpose of magnitude comparisons. Typical values are "3.0" or "3.1". The value "3.0" indicates that the processor implements XPath 3.0 plus the extensions defined in 21 Maps and 22 Processing JSON Data.

  • xsl:xsd-version, a number giving the version of XSD (XML Schema) implemented by the processor. The value will always be a string in the lexical space of the decimal datatype defined in XML Schema (see [XML Schema Part 2]). This allows the value to be converted to a number for the purpose of magnitude comparisons. Typical values are "1.0" or "1.1". This property is relevant even when the processor is not schema-aware, since the built-in datatypes for XSD 1.1 differ from those in XSD 1.0.

Some of these properties relate to the conformance levels and features offered by the processor: these options are described in 27 Conformance.

The actual values returned for the above properties are implementation-defined.

The set of system properties that are supported, in addition to those listed above, is also implementation-defined. Implementations must not define additional system properties in the XSLT namespace.

Error Conditions

[ERR XTDE1390] It is a dynamic error if the value supplied as the $property-name argument is not a valid QName, or if there is no namespace declaration in scope for the prefix of the QName. If the processor is able to detect the error statically (for example, when the argument is supplied as a string literal), then the processor may optionally signal this as a static error.

Notes

An implementation must not return the value 3.0 as the value of the xsl:version system property unless it is conformant to XSLT 3.0.

It is recognized that vendors who are enhancing XSLT 1.0 or 2.0 processors may wish to release interim implementations before all the mandatory features of this specification are implemented. Since such products are not conformant to XSLT 3.0, this specification cannot define their behavior. However, implementers of such products are encouraged to return a value for the xsl:version system property that is intermediate between 1.0 and 3.0, and to provide the element-available and function-available functions to allow users to test which features have been fully implemented.

20.4.5 fn:available-system-properties

Summary

Returns a list of system property names that are suitable for passing to the system-property function, as a sequence of QNames.

Signature
fn:available-system-properties() as xs:QName*
Properties

This function is deterministicFO30, context-independentFO30, and focus-independentFO30.

Rules

The function returns a sequence of QNames, being the names of the system properties recognized by the processor, in some implementation-dependent order.

The prefix part of a returned QName is implementation-dependent.

The function is deterministicFO30: that is, the set of available system properties does not vary during the course of a transformation.

Notes

The function returns a list of QNames, containing no duplicates.

It is intended that the QNames in this list should be suitable for passing to system-property. However, they must first be converted to the form expected by the system-property function, which is either a lexical QName or to an EQName in the form Q{uri}local. Because the prefix of the returned QName is unpredictable, the Q{uri}local is likely to be more convenient. Conversion of an xs:QName value to an EQName in Q{uri}local format can be achieved using the function:

<xsl:function name="f:QName-to-brace-notation" as="xs:string">
  <xsl:param name="qname" as="xs:QName"/>
  <xsl:sequence select="'Q{' || namespace-uri-from-QName($qname) || '}' 
                             || local-name-from-QName($qname)"/>
</xsl:function>