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

XQuery 4.0: An XML Query Language

W3C Editor's Draft 23 February 2026

This version:
https://qt4cg.org/specifications/xquery-40/
Most recent version of XQuery:
https://qt4cg.org/specifications/xquery-40/
Most recent Recommendation of XQuery:
https://www.w3.org/TR/2017/REC-xquery-31-20170321/
Editor:
Michael Kay, Saxonica <http://www.saxonica.com/>

This document is also available in these non-normative formats: XML.

Copyright © 2000 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

Abstract

XML is a versatile markup language, capable of labeling the information content of diverse data sources, including structured and semi-structured documents, relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these kinds of data, whether physically stored in XML or viewed as XML via middleware. This specification describes a query language called XQuery, which is designed to be broadly applicable across many types of XML data sources.

A list of changes made since XQuery 3.1 can be found in J Change Log.

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

2 Basics

2.3 External Resources and Security

Changes in 4.0 ⬇ ⬆

  1. This section (“External Resources and Security”) is new.  [Issue 2047 PR 2213 23 October 2025]

The XPath, XQuery, and XSLT languages provide a number of capabilities to access external resources. These include:

  • Functions such as doc, doc-available, unparsed-text, unparsed-text-lines, unparsed-text-available, collectionuri-collection, and unparsed-binary, and in XSLT, the document function and the xsl:source-document and xsl:merge instructions.

  • Static inclusion of code using import module in XQuery, or xsl:include, xsl:import, and xsl:use-package in XSLT.

  • Dynamic inclusion and execution of external code using the functions transform and load-xquery-module, and in XSLT, the xsl:evaluate instruction.

  • The ability to write to external resources using the xsl:result-document instruction in XSLT, or the put function in the XQuery Update Facility.

  • The ability to invoke arbitrary user-defined external functions (called extension functions in XSLT).

  • The ability to invoke vendor-defined external/extension functions; a notable example being the EXPath File library.

  • Access to environment variables and system properties using functions such as environment-variable, available-environment-variables, and (in XSLT) system-property.

  • Static inclusion of XSD schemas and schema documents using import schemain XQuery or xsl:import-schema in XSLT, or indirectly using xs:import, xs:include, xs:redefine, or xs:override in XSD schema documents.

  • Dynamic loading of XSD schema documents (directly or indirectly) using the xsd-validator function.

  • The ability to parse XML or HTML documents that contain references to external entities, for example by using the parse-xml and parse-html functions.

  • The ability to parse XML documents in a way that causes other external resources to be fetched, for example by activating XInclude, or by performing XSD validation using xsi:schema-location.

  • Implicit access to third-party libraries supporting (for example) collations or localization.

[Definition: The static context includes a boolean property called trusted that determines whether external resources are available.] This may take the following values:

  1. false: No external resources are available other than resources explicitly made available by the caller through some trusted implementation-defined mechanism.

    [Definition: ]Code executing with trusted set to false is said to be untrusted.

  2. true: Trusted code has access to all the resources available to its immediate caller.

The functions transform and load-xquery-module, and the XSLT instruction xsl:evaluate, have an option allowing the trust level of the executed code to be set:

  1. If trusted is set to true, the invoked code executes with the same trust level as its caller.

  2. If trusted is set to false, the invoked code is not able to access any external resources other than resources explicitly made available using an implementation defined mechanism under the control of the caller.

Some resources, such as XML documents, may themselves contain references to other resources. For example, an XML document may reference external entities (including an external DTD). External entity expansion is recognized as a known security risk. Functions that invoke XML parsing (such as parse-xml, doc, or collection) therefore have a trusted option indicating whether the document being parsed is trusted to access external entities. Such access is allowed only if (a) the trusted option is set to true, or (b) access to the external entity in question is explicitly enabled by the caller.

Note:

The term explicitly enabled is not intended to mean that every resource to which access is permitted must be individually listed. The mechanism for enabling access might provide access to a class of resources (for example, all resources accessible using the HTTPS protocol, or all resources within the containing XML database having particular access permissions). The mechanism might also take account of other criteria, for example it might impose limits on the size or other characteristics of the resources accessed.

It is recommended that any external API used to invoke XPath, XQuery, or XSLT processing should similarly offer the ability to indicate whether the code being executed is trusted.

In the interests of security, the default for these options is lowfalse. However, for backwards compatibility reasons, processors may provide an option whereby a trusted user can change the default.

In general, when an application requests access to an external resource which is not available because the application is untrusted, the processor should behave in the same way as if the resource did not exist. However, the processor may choose to disclose in its diagnostics why the request was unsuccessful.

A processor may (but is not required to) limit an application’s consumption of resources such as CPU cycles and memory when the application is untrusted.

[Definition: The term available documents refers (TODO: for the time being) to the set of XML documents that an application is able to access by URI.]