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 and XPath Data Model 4.0

W3C Editor's Draft 23 February 2026

This version:
https://www.w3.org/TR/2000/REC-xpath-datamodel-40-20000101/
Latest version of XQuery and XPath Data Model 4.0:
https://www.w3.org/TR/xpath-datamodel-40/
Previous versions of XQuery and XPath Data Model 4.0:
https://www.w3.org/TR/2017/PR-xpath-datamodel-31-20170117/
https://www.w3.org/TR/2016/CR-xpath-datamodel-31-20161213/
https://www.w3.org/TR/2014/CR-xpath-datamodel-31-20141218/
Most recent version of XQuery and XPath Data Model 4:
https://www.w3.org/TR/xpath-datamodel-4/
Most recent version of XQuery and XPath Data Model:
https://www.w3.org/TR/xpath-datamodel/
Most recent Recommendation of XQuery and XPath Data Model:
https://www.w3.org/TR/2014/REC-xpath-datamodel-30-20140408/
Editors:
Norm Tovey-Walsh, Saxonica, Ltd <norm@saxonica.com>
John Snelson (XML Query WG), MarkLogic Corporation <john.snelson@marklogic.com>
Andrew Coleman (XML Query WG), IBM Hursley Laboratories <andrew_coleman@uk.ibm.com>

Please check the errata for any errors or issues reported since publication.

See also translations.

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

This document defines the XQuery and XPath Data Model 4.0, which is the data model of [XML Path Language (XPath) 4.0], [XSL Transformations (XSLT) Version 4.0], and [XQuery 4.0: An XML Query Language], and any other specifications that reference it. This document is the result of joint work by the [XSLT Working Group] and the [XML Query Working Group].

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document is governed by the 1 March 2017 W3C Process Document.

This is a Recommendation of the W3C. It was jointly developed by the W3C XML Query Working Group and the W3C XSLT Working Group, each of which is part of the XML Activity.

This Editor's Draft specifies the XQuery and XPath Data Model (XDM) version 4.0, a fully compatible extension of XDM version 3.1.

This specification is designed to be referenced normatively from other specifications defining a host language for it; it is not intended to be implemented outside a host language. The implementability of this specification has been tested in the context of its normative inclusion in host languages defined by the XQuery 3.1 and XSLT 3.0 specifications; see the XQuery 3.1 implementation report (and, in the future, the WGs expect that there will also be an XSLT 3.0 implementation report) for details.

No substantive changes have been made to this specification since its publication as a Proposed Recommendation.

Please report errors in this document using W3C's public Bugzilla system (instructions can be found at https://www.w3.org/XML/2005/04/qt-bugzilla). If access to that system is not feasible, you may send your comments to the W3C XSLT/XPath/XQuery public comments mailing list, public-qt-comments@w3.org. It will be very helpful if you include the string “[XDM31]” in the subject line of your report, whether made in Bugzilla or in email. Please use multiple Bugzilla entries (or, if necessary, multiple email messages) if you have more than one comment to make. Archives of the comments and responses are available at https://lists.w3.org/Archives/Public/public-qt-comments/.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures (W3C XML Query Working Group) and a public list of any patent disclosures (W3C XSLT Working Group) made in connection with the deliverables of each group; these pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Dedication

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

7 Function Items, Maps, and Arrays

7.2 Map Items

Changes in 4.0 ⬇ ⬆

  1. Constructors are added, and the single accessor function is now an iterator over the key/value pairs in the map.  [Issue 1335  20 July 2024]

  2. Ordered maps are introduced.  [Issue 1651 PR 1703 14 January 2025]

[Definition: A map item (also called simply a map) is an item that represents an ordered sequence of key/value pairs, in which the keys are unique.] In other languages this is sometimes called a hash, dictionary, or associative array. The keys are atomic items, and each key in the map is unique (there is no other key to which it is equal). Each key is associated with a value that may be any sequence of zero or more items. There is no uniqueness constraint on values, only on keys. The semantics of equality when comparing keys are described in Section 13.2.1 fn:atomic-equalFO.

[Definition: The key/value pairs in a map are referred to as entries.]

[Definition: A map containing exactly one entry is referred to as a single-entry map.]

[Definition: A map containing no entries is referred to as an empty map.]

Note:

Maps have no intrinsic identity separate from their content. A map can be given a transient identity, represented by an id property in its label, by applying the fn:pin function. This property is expected to be used in defining operations for deep update of maps.

[Definition: The order of entries in a map is referred to as entry order.] The entry order affects the result of functions such as map:keys and map:for-each, and also determines the order of entries when a map is serialized using the JSON output method.

Constructor and accessor functions for maps are defined in the following sections.

7.2.2 map-put Constructor

dm:map-put($map as map(*), $key as xs:anyAtomicType, $value as item()*) as map(*)

The dm:map-put constructor returns a map based on the contents of a supplied map.

The key/value pairs in the returned map are as follows, in order:

  • One key/value pair for every key/value pair present in $map whose key is not equal to $key; plus

  • One key/value pair whose key is $key and whose associated value is $value.

The entry order in the returned map reflects the entry order in the supplied $map. If the key of the new entry was present in $map then the new entry replaces that entry retaining its current position; otherwise, the new entry is added after all existing entries.

  1. If $map includes a key/value pair (call it E0) whose key is atomic-equal to $key, then:

    1. All the key/value pairs in $map that precede E0 in entry order.

    2. A key/value pair whose key is either $key or the existing key of E0, and whose value part is $value. It is implementation dependent which key is chosen.

      Note:

      Most commonly, the two keys will be indistinguishable. However, they may have different type annotations (for example, xs:string versus xs:untypedAtomic, or they may be date/time values in different timezones.

    3. All the key/value pairs in $map that follow E0 in entry order.

  2. Otherwise:

    1. All the key/value pairs in $map.

    2. A key/value pair whose key is $key and whose value part is $value.

Note:

The entry order in the returned map reflects the entry order in the supplied $map. If the key of the new entry was present in $map then the new entry replaces that entry retaining its current position; otherwise, the new entry is added after all existing entries.

The function is exposed in XPath through the function map:put.