View Old View New View Both View Only Previous Next

This draft contains only sections that have differences from the version that it modified.

W3C

XPath and XQuery Functions and Operators 4.0

W3C Editor's Draft 23 February 2026

This version:
https://qt4cg.org/specifications/xpath-functions-40/
Latest version of XPath and XQuery Functions and Operators 4.0:
https://qt4cg.org/specifications/xpath-functions-40/
Most recent Recommendation of XPath and XQuery Functions and Operators:
https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/
Editor:
Michael Kay, Saxonica <http://www.saxonica.com/>

This document is also available in these non-normative formats: Specification in XML format and XML function catalog.


Abstract

This document defines constructor functions, operators, and functions on the datatypes defined in [XML Schema Part 2: Datatypes Second Edition] and the datatypes defined in [XQuery and XPath Data Model (XDM) 4.0]. It also defines functions and operators on nodes and node sequences as defined in the [XQuery and XPath Data Model (XDM) 4.0]. These functions and operators are defined for use in [XML Path Language (XPath) 4.0] and [XQuery 4.0: An XML Query Language] and [XSL Transformations (XSLT) Version 4.0] and other related XML standards. The signatures and summaries of functions defined in this document are available at: http://www.w3.org/2005/xpath-functions/.

A summary of changes since version 3.1 is provided at H Changes since 3.1.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This document is a working draft developed and maintained by a W3C Community Group, the XQuery and XSLT Extensions Community Group unofficially known as QT4CG (where "QT" denotes Query and Transformation). This draft is work in progress and should not be considered either stable or complete. Standard W3C copyright and patent conditions apply.

The community group welcomes comments on the specification. Comments are best submitted as issues on the group's GitHub repository.

The community group maintains two extensive test suites, one oriented to XQuery and XPath, the other to XSLT. These can be found at qt4tests and xslt40-test respectively. New tests, or suggestions for correcting existing tests, are welcome. The test suites include extensive metadata describing the conditions for applicability of each test case as well as the expected results. They do not include any test drivers for executing the tests: each implementation is expected to provide its own test driver.

Dedication

The publications of this community group are dedicated to our co-chair, Michael Sperberg-McQueen (1954–2024).


17 External resources and data formats

These functions in this section access resources external to a query or stylesheet, and convert between external file formats and their XPath and XQuery data model representation.

17.1 Accessing external information

The functions in this section provide access to resources (such as files) in the external environment.

FunctionMeaning
fn:docRetrieves a document using a URI supplied as an xs:string, and returns the corresponding document node.
fn:doc-availableThe function returns true if and only if the function call fn:doc($source, $options) would return a document node.
fn:collectionReturns a sequence of items identified by a collection URI; or a default collection if no URI is supplied.
fn:uri-collectionReturns a sequence of xs:anyURI values representing the URIs in a URI collection.
fn:unparsed-textThe fn:unparsed-text function reads an external resource (for example, a file) and returns a string representation of the resource.
fn:unparsed-text-linesThe fn:unparsed-text-lines function reads an external resource (for example, a file) and returns its contents as a sequence of strings, one for each line of text in the string representation of the resource.
fn:unparsed-text-availableAllows an application to determine whether a call on fn:unparsed-text with particular arguments would succeed.
fn:unparsed-binaryThe fn:unparsed-binary function reads an external resource (for example, a file) and returns its contents in binary.
fn:environment-variableReturns the value of a system environment variable, if it exists.
fn:available-environment-variablesReturns a list of environment variable names that are suitable for passing to fn:environment-variable, as a (possibly empty) sequence of strings.

17.1.9 fn:environment-variable

Summary

Returns the value of a system environment variable, if it exists.

Signature
fn:environment-variable(
$nameas xs:string
) as xs:string?
Properties

This function is deterministic, context-dependent, and focus-independent. It depends on environment variables.

Rules

The set of available environment variablesXP is a set of (name, value) pairs forming part of the dynamic context, in which the name is unique within the set of pairs. The name and value are arbitrary strings.

If the $name argument matches the name of one of these pairs, the function returns the corresponding value.

If there is no environment variable with a matching name, the function returns the empty sequence.

The collation used for matching names is implementation-defined, but must be the same as the collation used to ensure that the names of all environment variables are unique.

The function is deterministic, which means that if it is called several times within the same execution scope, with the same arguments, it must return the same result.

Environment variable names starting and ending with the character U+003D (EQUALS SIGN, =) have a special meaning and are used to obtain information about the processor (for example, XSLT or XQuery processor) under which the function is being evaluated, or about the environment in which it is running. These variables are as follows:

Built-in Environment Variables
NameValue

=xpath-version=

The version of XPath supported by the processor, for example the string "4.0". The value will always be a string in the lexical space of the xs:decimal data type.

=xsd-version=

The version of XSD (XML Schema) implemented by the processor, for example the string "1.0" or "1.1". The value will always be a string in the lexical space of the xs:decimal data type. The value is relevant even if the processor is not schema-aware, because the built-in datatypes for XSD 1.1 differ from those of XSD 1.0.

=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.

=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.

=schema-aware=

Returns the string "yes" if the processor offers the ability to add schema components to the static context, using the schema import mechanism of XSLT or XQuery, or otherwise. The property indicates whether the processor has this capability, not whether a schema has actually been imported.

=accepts-typed-data=

Returns the string "yes" if the processor is capable of handling nodes with a type annotation other than xs:untyped and xs:untypedAtomic, or "no" otherwise.

In the case of XSLT, if the call on environment-variable appears in a static expression (for example, in a use-when attribute), then the relevant static context is that of the containing XSLT element.

Notes

On many platforms, the term “environment variable” has a natural meaning in terms of facilities provided by the operating system. This interpretation of the concept does not exclude other interpretations, such as a mapping to a set of configuration parameters in a database system.

Environment variable names are usually case sensitive. Names are usually of the form (letter|_) (letter|_|digit)*, but this varies by platform. The naming convention for built-in names such as =xpath-version= is chosen to avoid any conflict with names allowed by popular operating systems.

On some platforms, there may sometimes be multiple environment variables with the same name; in this case, it is implementation-dependent as to which is returned; see for example [POSIX.1-2008] (Chapter 8, Environment Variables). Implementations may use prefixes or other naming conventions to disambiguate the names.

The requirement to ensure that the function is deterministic means in practice that the implementation must make a snapshot of the environment variables at some time during execution, and return values obtained from this snapshot, rather than using live values that are subject to change at any time.

Operating system environment variables may be associated with a particular process, while queries and stylesheets may execute across multiple processes (or multiple machines). In such circumstances implementations may choose to provide access to the environment variables associated with the process in which the query or stylesheet processing was initiated.

In operating system shell languages, environment variables are often embellished with punctuation characters: for example $VARIABLE_NAME on Unix-based systems, or %VARIABLE_NAME% on Windows. The punctuation characters are not part of the name, and should not be present in the value of $name.

Security advice: UntrustedXPQueries applicationsfrom untrusted sources should not be permitted unrestricted access to environment variables. For example, the name of the account under which athe query is running may be useful information to a would-be intruder. An implementation may therefore choose to restrict access to the environment, or may provide a facility to make fn:environment-variable always return the empty sequence.

This function overlaps with the capability offered by the system-property function in XSLT. It has been extended to provide information about the processor, primarily in order to offer a similar capability for non-XSLT environments.

The values returned for properties such as "=xpath-version=" may depend on how the processor has been configured.

The function fn:environment-variable has been available since XPath 3.0, and although the properties such as "=xpath-version=" are first defined in 4.0, an XPath 3.0 or 3.1 implementation that recognized these properties would be entirely conformant.

Examples
ExpressionResult
environment-variable("=xpath-version=")

"4.0"

17.1.10 fn:available-environment-variables

Summary

Returns a list of environment variable names that are suitable for passing to fn:environment-variable, as a (possibly empty) sequence of strings.

Signature
fn:available-environment-variables() as xs:string*
Properties

This function is deterministic, context-dependent, and focus-independent. It depends on environment variables.

Rules

The function returns a sequence of strings, being the names of the environment variables in the dynamic context in some implementation-dependent order.

The function is deterministic: that is, the set of available environment variables does not vary during evaluation.

Notes

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

It is intended that the strings in this list should be suitable for passing to fn:environment-variable.

See also the note on security under the definition of the fn:environment-variable function. If access to environment variables has been disabled, fn:available-environment-variables always returns the empty sequence.

The result includes the built-in environment variables such as =xpath-version= that are always available.