W3C

XQuery Update Facility 1.0

W3C Candidate Recommendation 1 August 2008

This version:
http://www.w3.org/TR/2008/CR-xquery-update-10-20080801/
Latest version:
http://www.w3.org/TR/xquery-update-10/
Previous versions:
http://www.w3.org/TR/2008/CR-xquery-update-10-20080314/, http://www.w3.org/TR/2007/WD-xquery-update-10-20070828/, http://www.w3.org/TR/2006/WD-xqupdate-20060711/
Editors:
Don Chamberlin, IBM Almaden Research Center
Daniela Florescu, Oracle <dana.florescu@oracle.com>
Jim Melton, Oracle <jim.melton@oracle.com>
Jonathan Robie, Red Hat <jonathan.robie@redhat.com>
Jérôme Siméon, IBM T.J. Watson Research Center <simeon@us.ibm.com>

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


Abstract

This document defines an update facility that extends the XML Query language, XQuery. The XQuery Update Facility provides expressions that can be used to make persistent changes to instances of the XQuery 1.0 and XPath 2.0 Data Model.

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 http://www.w3.org/TR/.

W3C publishes a Candidate Recommendation, as described in the Process Document, to indicate that the document is believed to be stable and to encourage implementation by the developer community. The publication of this document constitutes a call for implementations of this specification.

This document has been developed by the W3C XML Query Working Group, which is part of the XML Activity. It will remain a Candidate Recommendation until at least 20 June 2008. The Working Group expects to advance this specification to Recommendation Status.

The XML Query Working Group intends to submit this document for consideration as a W3C Proposed Recommendation as soon as the following conditions are met:

  1. A test suite is available that tests each identified XQuery Update Facility feature, both required and optional.

  2. Minimal Conformance to this specification, as defined in [5.1 Minimal Conformance], has been demonstrated by at least two distinct implementations, at least one of which uses the XQuery human-readable syntax defined in this specification.

  3. The Working Group has responded formally to all issues raised during the CR period against this document.

Once the entrance criteria for Proposed Recommendation have been achieved, the Director will be requested to advance this document to Proposed Recommendation status. Working closely with the developer community, we expect to show evidence of implementations by approximately 31 August 2008.

The following features are considered to be at risk:

They may be removed if implementations of them do not exist at the end of the Candidate Recommendation period.

The XML Query WG is republishing this document on 1 August 2008, to reflect changes made in response to comments received so far during the Candidate Recommendation period.

The WG still solicits comment on a key design principle of this specification: As indicated in [2.1 Extensions to the Processing Model], expressions may return either a value or a pending update list, but not both. We specifically solicit feedback on that decision.

A Test Suite for this document is under development. Implementors are encouraged to run this test suite and report their results. The Test Suite can be found at http://dev.w3.org/2007/xquery-update-10-test-suite/. In addition, a preliminary implementation report is available at http://dev.w3.org/2007/xquery-update-10-test-suite/results/.

This document incorporates changes made against the Candidate Recommendation of 14 March 2008. Changes to this document since the Candidate Recommendation are detailed in [H Revision Log].

Please report errors in this document using W3C's public Bugzilla system (instructions can be found at http://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 “[UPD]” 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 http://lists.w3.org/Archives/Public/public-qt-comments/.

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes 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.

Table of Contents

1 Introduction
    1.1 Terminology
2 Extensions to XQuery 1.0
    2.1 Extensions to the Processing Model
    2.2 Extensions to the Prolog
        2.2.1 Revalidation Declaration
        2.2.2 Variable Declaration
        2.2.3 Function Declaration
    2.3 Extensions to the Static Context
    2.4 New Kinds of Expressions
        2.4.1 Insert
        2.4.2 Delete
        2.4.3 Replace
            2.4.3.1 Replacing a Node
            2.4.3.2 Replacing the Value of a Node
        2.4.4 Rename
        2.4.5 Transform
        2.4.6 Compatibility of Updating Expressions
    2.5 Extensions to Existing Expressions
        2.5.1 FLWOR Expression
        2.5.2 Typeswitch Expression
        2.5.3 Conditional Expression
        2.5.4 Comma Expression
        2.5.5 Parenthesized Expression
        2.5.6 Function Call
        2.5.7 Other Expressions
    2.6 Extensions to Built-in Function Library
        2.6.1 fn:put
3 Update Operations
    3.1 Update Primitives
        3.1.1 upd:insertBefore
        3.1.2 upd:insertAfter
        3.1.3 upd:insertInto
        3.1.4 upd:insertIntoAsFirst
        3.1.5 upd:insertIntoAsLast
        3.1.6 upd:insertAttributes
        3.1.7 upd:delete
        3.1.8 upd:replaceNode
        3.1.9 upd:replaceValue
        3.1.10 upd:replaceElementContent
        3.1.11 upd:rename
        3.1.12 upd:put
    3.2 Update Routines
        3.2.1 upd:mergeUpdates
        3.2.2 upd:applyUpdates
        3.2.3 upd:revalidate
        3.2.4 upd:removeType
        3.2.5 upd:setToUntyped
4 Static Typing Feature
    4.1 Overview and notations
    4.2 Change to Static Typing Rules of XQuery 1.0
    4.3 Core Grammar
    4.4 XQuery Update Facility 1.0 Prolog
    4.5 XQuery Update Facility 1.0 Expressions
        4.5.1 Insert
        4.5.2 Delete
        4.5.3 Replace
        4.5.4 Rename
        4.5.5 Transform
        4.5.6 Examples
5 Conformance
    5.1 Minimal Conformance
    5.2 Optional Features
        5.2.1 Update Facility Static Typing Feature
6 XQueryX Conformance

Appendices

A EBNF for XQuery 1.0 Grammar with Update extensions
    A.1 Terminal Symbols
B Implementation-Defined Items
C References
    C.1 Normative References
    C.2 Non-normative References
D Error Conditions
    D.1 New Error Codes
    D.2 Amendments to Existing Error Codes
E XML Syntax (XQueryX) for XQuery Update Facility 1.0
    E.1 Schema
    E.2 Stylesheet
    E.3 Example
        E.3.1 XQuery Representation
        E.3.2 XQueryX Representation
        E.3.3 Transformed XQuery Representation
F Glossary (Non-Normative)
G Rationale for Precedence of Update Primitives (Non-Normative)
H Revision Log (Non-Normative)


1 Introduction

This document defines the syntax and semantics of an extension to [XQuery 1.0] called the XQuery Update Facility 1.0. This language extension is designed to meet the requirements for updating instances of the [XQuery/XPath Data Model (XDM)], as defined in [XQuery Update Facility Requirements].

The XQuery Update Facility 1.0 provides facilities to perform any or all of the following operations on an XDM instance:

Additionally, this document defines an XML syntax for the XQuery Update Facility 1.0. The most recent versions of the two XQueryX XML Schemas and the XQueryX XSLT stylesheet for the XQuery Update Facility 1.0 are available at http://www.w3.org/2007/xquery-update-10/xquery-update-10-xqueryx.xsd, http://www.w3.org/2007/xquery-update-10/xquery-update-10-xqueryx-redef.xsd, and http://www.w3.org/2007/xquery-update-10/xquery-update-10-xqueryx.xsl, respectively.

1.1 Terminology

[Definition: Within this document, the term XQuery refers to the language specified by [XQuery 1.0].] [Definition: The term data model refers to the data model specified by [XQuery/XPath Data Model (XDM)].] [Definition: The term XDM instance denotes an unconstrained sequence of zero or more nodes and/or atomic values as defined by the data model.] [Definition: The term node identity denotes the unique identity that is a property of every node in an XDM instance (see Section 2.3 Node IdentityDM.)]

As described in Section 3.3.3 QNames and NOTATIONSDM, names in XQuery are qualified names (QNames) that consist of an optional namespace prefix, a local name, and an optional namespace URI. [Definition: The implied namespace binding of a QName is the association of its namespace prefix (or absence thereof) with its namespace URI (or absence thereof).] [Definition: Two namespace bindings are said to conflict if their namespace prefixes (or absence thereof) are the same but their namespace URI's (or absence thereof) are different.] Update operations that result in conflicting namespace bindings generally raise errors, as described in this document.

2 Extensions to XQuery 1.0

The basic building block of XQuery is the expression. XQuery 1.0 provides several kinds of expressions that can be composed with each other in arbitrary ways. An XQuery 1.0 expression takes zero or more XDM instances as input and returns an XDM instance as a result. In XQuery 1.0, an expression never modifies the state of an existing node; however, constructor expressions create new nodes with new node identities.

XQuery Update Facility 1.0 introduces a new category of expression called an updating expression, which can potentially modify the state of an existing node.

The extensions to XQuery 1.0 provided by XQuery Update Facility 1.0 may be characterized as follows:

  1. XQuery Update Facility 1.0 introduces five new kinds of expressions, called insert, delete, replace, rename, and transform expressions, and specifies the syntax and semantics of each new kind of expression.

  2. XQuery Update Facility 1.0 classifies XQuery expressions into the following categories:

    1. [Definition: A basic updating expression is an insert, delete, replace, or rename expression, or a call to an updating function.]

    2. [Definition: An updating expression is a basic updating expression or any expression (other than a transform expression) that directly contains an updating expression.]

      Note:

      The definition of an updating expression is recursive.

    3. [Definition: A simple expression is any XQuery expression that is not an updating expression.]

    4. [Definition: A vacuous expression is a simple expression that can only return an empty sequence or raise an error.]

  3. XQuery Update Facility 1.0 defines the places in which each type of expression can be used. In so doing, it makes small extensions to the syntax and semantics of certain existing expressions.

The classification of each expression into one of the above categories is performed by static analysis, according to rules specified in this document for each type of expression.

2.1 Extensions to the Processing Model

XQuery Update Facility 1.0 defines the following extensions to the XQuery processing model:

  1. In XQuery 1.0, the result of each expression is an XDM instance. XQuery Update Facility 1.0 extends the XQuery processing model so that the result of an expression consists of both an XDM instance and a pending update list (either or both of which may be empty). [Definition: A pending update list is an unordered collection of update primitives, which represent node state changes that have not yet been applied.] The term "result" used in Section 2.3.4 Errors and OptimizationXQ includes both the XDM instance and the pending update list returned by an expression.

    Note:

    In XQuery Update Facility 1.0, no expression returns both a non-empty XDM instance and a non-empty pending update list.

  2. XQuery Update Facility 1.0 also defines a set of update operations. [Definition: Update operations are used in defining the semantics of XQuery updates, but are not directly available to users. Update operations are defined in [3 Update Operations].] Update operations fall into the following categories:

    1. [Definition: Update primitives are the components of pending update lists. Each update primitive represents a node state change that has not yet been applied.] [Definition: The first argument of an update primitive, called its target node, is the principal node to be affected by the update primitive.] Update primitives are held on pending update lists until they are made effective by a upd:applyUpdates operation.

    2. [Definition: Update routines are sequences of actions that are used in the definition of XQuery semantics but do not appear on pending update lists.] upd:applyUpdates is an example of an update routine.

  3. If the outermost expression in a query returns a pending update list, upd:applyUpdates is implicitly invoked, supplying as arguments (a) the pending update list, and (b) the value of the revalidation mode in the static context of the main query module. This invocation of upd:applyUpdates may raise an error (see [3.2.2 upd:applyUpdates] for possible error codes.)

[Definition: A snapshot is a scope within which expressions are evaluated with respect to a fixed XDM instance and updates are held pending.] A snapshot is terminated by invocation of the upd:applyUpdates operation. XQuery Update Facility 1.0 defines an entire query as one snapshot.

This specification defines the semantics of updates to an XDM instance. Propagation of these updates to an underlying persistent store (if any) is beyond the scope of this specification.

2.2 Extensions to the Prolog

2.2.1 Revalidation Declaration

[7]    Setter    ::=    BoundarySpaceDecl | DefaultCollationDecl | BaseURIDecl | ConstructionDecl | OrderingModeDecl | EmptyOrderDecl | RevalidationDecl | CopyNamespacesDecl
[141]    RevalidationDecl    ::=    "declare" "revalidation" ("strict" | "lax" | "skip")

The Prolog is extended by adding a new kind of Setter called a revalidation declaration. [Definition: A revalidation declaration sets the revalidation mode in the static context, overriding any implementation-defined default.] If a Prolog contains more than one revalidation declaration, a static error is raised [err:XUST0003]. Revalidation mode controls the process by which type information is recovered for an updated document, as described in [3.2.3 upd:revalidate]

Support for each of the three revalidation modes is implementation-defined; however, an implementation must support at least one of the three revalidation modes. If a revalidation declaration specifies a revalidation mode that is not supported by the current implementation, a static error is raised [err:XUST0026].

2.2.2 Variable Declaration

The following rule is added: If the expression on the right-hand-side of a variable declaration (the initializing expression) is not a simple expression, a static error is raised [err:XUST0001].

2.2.3 Function Declaration

[26]    FunctionDecl    ::=    "declare" "updating"? "function" QName "(" ParamList? ")" ("as" SequenceType)? (EnclosedExpr | "external")

The syntax of a function declaration is extended to include an optional keyword: updating. [Definition: Functions whose declarations contain the keyword updating, and certain built-in functions including fn:put, are called updating functions.] The semantics of a function declaration, described in Section 4.15 of [XQuery 1.0], are extended as follows:

  1. If updating is not specified:

    1. If external is not specified, the EnclosedExpr in the function declaration must be a simple expression; otherwise a static error is raised [err:XUST0001].

    2. If external is specified, the external function must not return a non-empty pending update list; otherwise a dynamic error is raised [err:XUDY0018].

  2. If updating is specified:

    1. A return type must not be specified [err:XUST0028].

    2. If external is not specified, the EnclosedExpr in the function declaration must be an updating expression or a vacuous expression; otherwise a static error is raised [err:XUST0002].

    3. If external is specified, the external function may return a non-empty pending update list but it must not return a non-empty XDM instance; otherwise a dynamic error is raised [err:XUDY0019].

The means by which an external function returns an XDM instance or a pending update list is implementation-defined.

The following example illustrates a declaration of an updating function.

  • This function takes an element, a QName, and an atomic value. If the given element has an attribute with the given QName, the function updates the attribute with the given value; otherwise it inserts a new attribute with the given name and value.

    declare updating function 
       upsert($e as element(), 
              $an as xs:QName, 
              $av as xs:anyAtomicType) 
       {
       let $ea := $e/attribute()[fn:node-name(.) = $an]
       return
          if (fn:empty($ea))
          then insert node attribute {$an} {$av} into $e
          else replace value of node $ea with $av
       }
    

2.3 Extensions to the Static Context

  1. The following definition is added to the XQuery static context (documented in Section 2.1.1 Static ContextXQ):

    [Definition: Revalidation mode, which may be strict, lax, or skip, is a component of the static context that controls the behavior of the upd:revalidate operation.]

  2. The following entry is added to the table of static context components (documented in Section C.1 Static Context ComponentsXQ):

    • Component: Revalidation mode

    • Default initial value: lax.

    • Can be overwritten by an implementation: Yes (implementation defined.)

    • Can be overwritten by a query: Yes, overwritable by declaration in query prolog.

    • Scope: Module.

    • Consistency rules: Must be strict, lax, or skip.

2.4 New Kinds of Expressions

[32]    ExprSingle    ::=    FLWORExpr
| QuantifiedExpr
| TypeswitchExpr
| IfExpr
| InsertExpr
| DeleteExpr
| RenameExpr
| ReplaceExpr
| TransformExpr
| OrExpr

XQuery Update Facility 1.0 extends the syntax of ExprSingle by adding five new kinds of expressions, called insert, delete, replace, rename, and transform expressions. The syntax and semantics of these expressions are described in the following sections.

Note:

In general, updating expressions cause a loss of type information from nodes that are affected by the update. Type information for these nodes may be recovered by a revalidation process at the end of the snapshot. For more details on type loss and recovery, see the update primitives associated with each updating expression; see also [3.2.4 upd:removeType] and [3.2.3 upd:revalidate].

2.4.1 Insert

[143]    InsertExpr    ::=    "insert" ("node" | "nodes") SourceExpr InsertExprTargetChoice TargetExpr
[142]    InsertExprTargetChoice    ::=    (("as" ("first" | "last"))? "into")
| "after"
| "before"
[147]    SourceExpr    ::=    ExprSingle
[148]    TargetExpr    ::=    ExprSingle

An insert expression is an updating expression that inserts copies of zero or more nodes into a designated position with respect to a target node. The keywords node and nodes may be used interchangeably, regardless of how many nodes are actually inserted. The position of the inserted nodes is determined as follows:

  • If before (or after) is specified:

    • The inserted nodes become the preceding (or following) siblings of the target node.

    • If multiple nodes are inserted by a single insert expression, the nodes remain adjacent and their order preserves the node ordering of the source expression.

    • If multiple groups of nodes are inserted by multiple insert expressions in the same snapshot, adjacency and ordering of nodes within each group is preserved but ordering among the groups is implementation-dependent.

  • If as first into (or as last into) is specified:

    • The inserted nodes become the first (or last) children of the target node.

    • If multiple nodes are inserted by a single insert expression, the nodes remain adjacent and their order preserves the node ordering of the source expression.

    • If multiple groups of nodes are inserted by multiple insert expressions in the same snapshot, adjacency and ordering of nodes within each group is preserved but ordering among the groups is implementation-dependent.

  • If into is specified without as first or as last:

    • The inserted nodes become children of the target node.

    • If multiple nodes are inserted by a single insert expression, their order preserves the node ordering of the source expression.

    • The positions of the inserted nodes are chosen so as not to interfere with the intended position of nodes that are inserted with the specification before, after, as first into, or as last into. For example, If node B is inserted "after node A", no other node will be inserted between nodes A and B unless it is also inserted "after node A".

    • Subject to the above constraints, the positions of the inserted nodes among the children of the target node are implementation-dependent.

Examples:

  • Insert a year element after the publisher of the first book.

    insert node <year>2005</year>
        after fn:doc("bib.xml")/books/book[1]/publisher
    
  • Navigating by means of several bound variables, insert a new police report into the list of police reports for a particular accident.

    insert node $new-police-report
       as last into fn:doc("insurance.xml")/policies
          /policy[id = $pid]
          /driver[license = $license]
          /accident[date = $accdate]
          /police-reports
    

The semantics of an insert expression are as follows:

  1. SourceExpr must be a simple expression; otherwise a static error is raised [err:XUST0001]. SourceExpr is evaluated as though it were an enclosed expression in an element constructor (see Rule 1e in Section 3.7.1.3 ContentXQ). The result of this step is either an error or a sequence of nodes to be inserted, called the insertion sequence. If the insertion sequence contains a document node, the document node is replaced in the insertion sequence by its children. If the insertion sequence contains an attribute node following a node that is not an attribute node, a type error is raised [err:XUTY0004]. Let $alist be the sequence of attribute nodes in the insertion sequence. Let $clist be the remainder of the insertion sequence, in its original order.

    Note:

    Either $alist or $clist or both may be empty.

  2. The target expression must be a simple expression; otherwise a static error is raised [err:XUST0001]. The target expression is evaluated and checked as follows:

    1. If the result is an empty sequence, [err:XUDY0027] is raised.

    2. If any form of into is specified, the result must be a single element or document node; any other non-empty result raises a type error [err:XUTY0005].

    3. If before or after is specified, the result must be a single element, text, comment, or processing instruction node; any other non-empty result raises a type error [err:XUTY0006].

    4. If before or after is specified, the node returned by the target expression must have a non-empty parent property [err:XUDY0029].

    Let $target be the node returned by the target expression.

  3. If $alist is not empty and any form of into is specified, the following checks are performed:

    1. $target must be an element node [err:XUTY0022].

    2. No attribute node in $alist may have a QName whose implied namespace binding conflicts with a namespace binding in the "namespaces" property of $target [err:XUDY0023].

    3. Multiple attribute nodes in $alist may not have QNames whose implied namespace bindings conflict with each other [err:XUDY0024].

  4. If $alist is not empty and before or after is specified, the following checks are performed:

    1. parent($target) must be an element node [err:XUDY0030].

    2. No attribute node in $alist may have a QName whose implied namespace binding conflicts with a namespace binding in the "namespaces" property of parent($target) [err:XUDY0023].

    3. Multiple attribute nodes in $alist may not have QNames whose implied namespace bindings conflict with each other [err:XUDY0024].

  5. The result of the insert expression is an empty XDM instance and a pending update list constructed as follows:

    1. If as first into is specified, the pending update list consists of the following update primitives:

      1. If $alist is not empty, upd:insertAttributes($target, $alist)

      2. If $clist is not empty, upd:insertIntoAsFirst($target, $clist)

    2. If as last into is specified, the pending update list consists of the following update primitives:

      1. If $alist is not empty, upd:insertAttributes($target, $alist)

      2. If $clist is not empty, upd:insertIntoAsLast($target, $clist)

    3. If into is specified with neither as first nor as last, the pending update list consists of the following update primitives:

      1. If $alist is not empty, upd:insertAttributes($target, $alist)

      2. If $clist is not empty, upd:insertInto($target, $clist)

    4. If before is specified, let $parent be the parent node of $target. The pending update list consists of the following update primitives:

      1. If $alist is not empty, upd:insertAttributes($parent, $alist)

      2. If $clist is not empty, upd:insertBefore($target, $clist)

    5. If after is specified, let $parent be the parent node of $target. The pending update list consists of the following update primitives:

      1. If $alist is not empty, upd:insertAttributes($parent, $alist)

      2. If $clist is not empty, upd:insertAfter($target, $clist)

2.4.2 Delete

[144]    DeleteExpr    ::=    "delete" ("node" | "nodes") TargetExpr
[148]    TargetExpr    ::=    ExprSingle

A delete expression deletes zero or more nodes from an XDM instance. The keywords node and nodes may be used interchangeably, regardless of how many nodes are actually deleted. A delete expression is an updating expression.

Examples:

  • Delete the last author of the first book in a given bibliography.

    delete node fn:doc("bib.xml")/books/book[1]/author[last()]
    
  • Delete all email messages that are more than 365 days old.

    delete nodes /email/message
         [fn:currentDate() - date > xs:dayTimeDuration("P365D")]
    

The semantics of a delete expression are as follows:

  1. The target expression must be a simple expression; otherwise a static error is raised [err:XUST0001]. The target expression is evaluated. The result must be a sequence of zero or more nodes; otherwise a type error is raised [err:XUTY0007]. Let $tlist be the list of nodes returned by the target expression.

  2. If any node in $tlist has no parent, an implementation may (but is not required to) raise a dynamic error [err:XUDY0020].

  3. A new pending update list is created. For each node $tnode in $tlist, the following update primitive is appended to the pending update list: upd:delete($tnode). The resulting pending update list (together with an empty XDM instance) is the result of the delete expression.

Notes:

  • Since node deletions do not become effective until the end of a snapshot, they have no effect on variable bindings or on the set of available documents or collections within the current query.

  • The semantics of a delete expression are defined in terms of their effect on an XDM instance: the deleted nodes are detached from their parents after completion of the current query. The effects of a delete expression on persistent storage are beyond the scope of this specification.

2.4.3 Replace

[145]    ReplaceExpr    ::=    "replace" ("value" "of")? "node" TargetExpr "with" ExprSingle
[148]    TargetExpr    ::=    ExprSingle

A replace expression is an updating expression. A replace expression has two forms, depending on whether value of is specified.

2.4.3.1 Replacing a Node

If value of is not specified, a replace expression replaces one node with a new sequence of zero or more nodes. The replacement nodes occupy the position in the node hierarchy that was formerly occupied by the node that was replaced. For this reason, an attribute node can be replaced only by zero or more attribute nodes, and an element, text, comment, or processing instruction node can be replaced only by zero or more element, text, comment, or processing instruction nodes. Example:

  • Replace the publisher of the first book with the publisher of the second book.

    replace node fn:doc("bib.xml")/books/book[1]/publisher
    with fn:doc("bib.xml")/books/book[2]/publisher
    

The semantics of this form of replace expression are as follows:

  1. The expression following the keyword with must be a simple expression; otherwise a static error is raised [err:XUST0001]. This expression is evaluated as though it were an enclosed expression in an element constructor (see Rule 1e in Section 3.7.1.3 ContentXQ). Let $rlist be the node sequence that results from this evaluation. If $rlist contains a document node, the document node is replaced in $rlist by its children.

  2. The target expression must be a simple expression; otherwise a static error is raised [err:XUST0001]. The target expression is evaluated and checked as follows:

    1. If the result is an empty sequence, [err:XUDY0027] is raised.

    2. If the result is non-empty and does not consist of a single element, attribute, text, comment, or processing instruction node, [err:XUTY0008] is raised.

    3. If the result consists of a node whose parent property is empty, [err:XUDY0009] is raised.

    Let $target be the node returned by the target expression, and let $parent be its parent node.

  3. If $target is an element, text, comment, or processing instruction node, then $rlist must consist exclusively of zero or more element, text, comment, or processing instruction nodes [err:XUTY0010].

  4. If $target is an attribute node, then:

    1. $rlist must consist exclusively of zero or more attribute nodes [err:XUTY0011].

    2. No attribute node in $rlist may have a QName whose implied namespace binding conflicts with a namespace binding in the "namespaces" property of $parent [err:XUDY0023].

    3. Multiple attribute nodes in $rlist may not have QNames whose implied namespace bindings conflict with each other [err:XUDY0024].

  5. The result of the replace expression is an empty XDM instance and a pending update list consisting of the following update primitive: upd:replaceNode($target, $rlist)

2.4.3.2 Replacing the Value of a Node

If value of is specified, a replace expression is used to modify the value of a node while preserving its node identity. Example:

  • Increase the price of the first book by ten percent.

    replace value of node fn:doc("bib.xml")/books/book[1]/price
    with fn:doc("bib.xml")/books/book[1]/price * 1.1
    

The semantics of this form of replace expression are as follows:

  1. The expression following the keyword with must be a simple expression; otherwise a static error is raised [err:XUST0001]. This expression is evaluated as though it were the content expression of a text node constructor (see Section 3.7.3.4 of [XQuery 1.0].) The result of this step, in the absence of errors, is either a single text node or an empty sequence. Let $text be the result of this step.

  2. The target expression must be a simple expression; otherwise a static error is raised [err:XUST0001]. The target expression is evaluated and checked as follows:

    1. If the result is an empty sequence, [err:XUDY0027] is raised.

    2. If the result is non-empty and does not consist of a single element, attribute, text, comment, or processing instruction node, [err:XUTY0008] is raised.

    Let $target be the node returned by the target expression.

  3. If $target is an element node, the result of the replace expression is an empty XDM instance and a pending update list consisting of the following update primitive: upd:replaceElementContent($target, $text)

  4. If $target is an attribute, text, comment, or processing instruction node, let $string be the string value of the text node constructed in Step 1. If Step 1 did not construct a text node, let $string be a zero-length string. Then:

    1. If $target is a comment node, and $string contains two adjacent hyphens or ends with a hyphen, a dynamic error is raised [err:XQDY0072].

    2. If $target is a processing instruction node, and $string contains the substring "?>", a dynamic error is raised [err:XQDY0026].

    3. In the absence of errors, the result of a replace expression is an empty XDM instance and a pending update list containing the following update primitive: upd:replaceValue($target, $string).

2.4.4 Rename

[146]    RenameExpr    ::=    "rename" "node" TargetExpr "as" NewNameExpr
[148]    TargetExpr    ::=    ExprSingle
[149]    NewNameExpr    ::=    ExprSingle

A rename expression replaces the name property of a data model node with a new QName. A rename expression is an updating expression.

Examples:

  • Rename the first author element of the first book to principal-author.

    rename node fn:doc("bib.xml")/books/book[1]/author[1]
    as "principal-author"
    
  • Rename the first author element of the first book to the QName that is the value of the variable $newname.

    rename node fn:doc("bib.xml")/books/book[1]/author[1]
    as $newname
    

The semantics of a rename expression are as follows:

  1. The target expression must be a simple expression; otherwise a static error is raised [err:XUST0001]. The target expression is evaluated and checked as follows:

    1. If the result is an empty sequence, [err:XUDY0027] is raised.

    2. If the result is non-empty and does not consist of a single element, attribute, or processing instruction node, [err:XUTY0012] is raised.

    Let $target be the node returned by the target expression.

  2. NewNameExpr must be a simple expression; otherwise a static error is raised [err:XUST0001]. NewNameExpr is processed as follows:

    1. If $target is an element node, let $QName be the result of evaluating NewNameExpr as though it were the name expression of a computed element constructor (see Section 3.7.3.1 Computed Element ConstructorsXQ). If the namespace binding of $QName conflicts with any namespace binding in the namespaces property of $target, a dynamic error is raised [err:XUDY0023].

    2. If $target is an attribute node, let $QName be the result of evaluating NewNameExpr as though it were the name expression of a computed attribute constructor (see Section 3.7.3.2 Computed Attribute ConstructorsXQ). If $QName has a non-absent namespace URI, and if the namespace binding of $QName conflicts with any namespace binding in the namespaces property of the parent (if any) of $target, a dynamic error is raised [err:XUDY0023].

    3. If $target is a processing instruction node, let $NCName be the result of evaluating NewNameExpr as though it were the name expression of a computed processing instruction constructor (see Section 3.7.3.5 Computed Processing Instruction ConstructorsXQ), and let $QName be defined as fn:QName((), $NCName).

  3. The result of the rename expression is an empty XDM instance and a pending update list containing the following update primitive: upd:rename($target, $QName).

Note:

The effects of a rename expression are limited to its target node. Attributes and descendants of the target node are not affected. If a global change of names or namespaces is intended, some form of explicit iteration must be used. The following example illustrates such a global change. The example operates on the node bound to variable $root and all its attributes and descendants, changing all QNames with the prefix abc to have a new prefix xyz and a new namespace URI http://xyz/ns.

for $node in $root//abc:*
let $localName := fn:local-name($node),
    $newQName := fn:concat("xyz:", $localName)
return (
   rename node $node as fn:QName("http://xyz/ns", $newQName),
   for $attr in $node/@abc:*
   let $attrLocalName := fn:local-name($attr),
       $attrNewQName := fn:concat("xyz:", $attrLocalName)
   return
      rename node $attr as fn:QName("http://xyz/ns", $attrNewQName)
)

2.4.5 Transform

[150]    TransformExpr    ::=    "copy" "$" VarName ":=" ExprSingle ("," "$" VarName ":=" ExprSingle)* "modify" ExprSingle "return" ExprSingle

A transform expression can be used to create modified copies of existing nodes in an XDM instance. Each node created by a transform expression has a new node identity. The result of a transform expression is an XDM instance that may include both nodes that were created by the transform expression and other, previously existing nodes. A transform expression is a simple expression because it does not modify the value of any existing nodes.

Examples:

  • Return a sequence consisting of all employee elements that have Java as a skill, excluding their salary child-elements:

    for $e in //employee[skill = "Java"]
    return 
       copy $je := $e
       modify delete node $je/salary
       return $je
    
  • The following example copies a node, modifies the copy, and returns both the original node and the modified copy:

    let $oldx := /a/b/x
    return
       copy $newx := $oldx
       modify (rename node $newx as "newx", 
               replace value of node $newx by $newx * 2)
       return ($oldx, $newx)
    

    Note:

    No persistent changes to the underlying data result from this example.

A transform expression consists of three clauses, denoted by the keywords copy, modify, and return. The semantics of a transform expression are as follows:

  1. The copy clause contains one or more variable bindings, each of which consists of a variable name and an expression called the source expression. Each variable binding is processed as follows:

    1. The source expression must be a simple expression; otherwise a static error is raised [err:XUST0001].

    2. The result of evaluating the source expression must be a single node [err:XUTY0013]. Let $node be this single node.

    3. A new copy is made of $node and all nodes that have $node as an ancestor, collectively referred to as copied nodes. Each copied node receives a new node identity. The parent, children, and attributes properties of the copied nodes are set so as to preserve their inter-node relationships. Other properties of the copied nodes are determined as follows:

      1. For a copied element node, the type-name property is set to xs:untyped, and the nilled, is-id, and is-idrefs properties are set to false.

      2. For a copied attribute node, the type-name property is set to xs:untypedAtomic and the is-idrefs property is set to false. The is-id property is set to true if the qualified name of the attribute node is xml:id; otherwise it is set to false.

      3. The string value of each copied element and attribute node remains unchanged, and its typed value becomes equal to its string value as an instance of xs:untypedAtomic.

        Note:

        Implementations that store only the typed value of a node are required at this point to convert the typed value to a string form.

      4. If copy-namespaces mode in the static context specifies preserve, all in-scope-namespaces of the original element are retained in the new copy. If copy-namespaces mode specifies no-preserve, the new copy retains only those in-scope namespaces of the original element that are used in the names of the element and its attributes.

      5. All other properties of the copied nodes are preserved.

    4. The variable name is bound to the top-level copied node generated in the previous step. The scope of this variable binding includes all subexpressions of the containing transform expression that appear after the variable binding clause, including the source expressions of later variable bindings, but it does not include the source expression to which the current variable name is bound.

  2. The modify clause must contain either an updating expression, an empty expression ( ), or a call to the fn:error function; otherwise a static error is raised [err:XUST0002]. The expression in the modify clause is evaluated, resulting in a pending update list. If the target node of any update primitive on this pending update list is a node that was not newly created in Step 1, a dynamic error is raised [err:XUDY0014]. Let $pul be the pending update list generated by this step.

  3. Let $revalidation-mode be the value of the revalidation mode in the static context of the transform expression. The following update operation is invoked: upd:applyUpdates($pul, $revalidation-mode). The effect of this operation is to make the updates specified in the modify clause effective on the copied nodes.

    Note:

    In the event of incompatible updates, the upd:applyUpdates operation may raise an error, as described in [3.2.2 upd:applyUpdates].

  4. The return clause must contain a simple expression; otherwise a static error is raised [err:XUST0001]. The return clause is evaluated, and its result is the result of the transform expression. During evaluation of the return clause, changes applied to copied nodes by the preceding step are visible.

2.4.6 Compatibility of Updating Expressions

The rules defining compatibility of updating expressions within a snapshot are defined in [3.2.2 upd:applyUpdates].

Note:

The effect of these rules is as follows:

  1. If any node is affected by more than one rename expression within a snapshot, a dynamic error is raised [err:XUDY0015].

  2. If any node is affected by more than one replace expression (without value of being specified) within a snapshot, a dynamic error is raised [err:XUDY0016].

  3. If any node is affected by more than one replace value of expression within a snapshot, a dynamic error is raised [err:XUDY0017].

  4. If multiple calls to fn:put operate on the same URI in the same snapshot, a dynamic error is raised [err:XUDY0031].

  5. Within a given snapshot, if an element node E is the target of a replace value of expression, and the children of E are also modified by other expressions, the final children of E are determined by the replace value of expression. For example:

    • Suppose that $A is bound to an element node that has a child element named B. Suppose that the following expressions are evaluated in the same snapshot:

      replace node $A/B with <C>Hello</C>,
      replace value of node $A with <D>Goodbye</D>
      

      The expressions on the left and right side of the comma can be evaluated in any order. No error is raised. At the end of the snapshot, the children of $A will consist of a single text node with the content "Goodbye".

2.5 Extensions to Existing Expressions

XQuery Update Facility 1.0 provides extensions to the semantics of several existing kinds of XQuery expressions, as specified in this section.

2.5.1 FLWOR Expression

The syntax of the FLWOR expression is not changed. Its semantics are extended as follows:

  1. If a for, let, where, or order by clause contains an updating expression, a static error is raised [err:XUST0001].

  2. The return clause may contain any category of expression. The category of the FLWOR expression is the same as the category of the expression in its return clause (simple, vacuous, or updating.)

  3. If the return clause contains a simple expression, the semantics of the FLWOR expression are as specified in Section 3.8 FLWOR ExpressionsXQ.

  4. If the return clause contains an updating expression, the semantics of the FLWOR expression are as follows:

    1. The semantics of the for, let, where, and order by clauses are as specified in Section 3.8 FLWOR ExpressionsXQ. These clauses generate a stream of tuples of bound variables.

    2. For each tuple generated by the previous step, the updating expression in the return clause is evaluated, resulting in a pending update list.

    3. All the pending update lists generated by the previous step are merged by successive invocations of the upd:mergeUpdates operation. The resulting merged pending update list is the result of the FLWOR expression.

      Note:

      In the event of incompatible updates, the upd:mergeUpdates operation may raise an error, as described in [3.2.1 upd:mergeUpdates].

The following example illustrates the use of an updating expression in a FLWOR expression:

  • Update an inventory of parts according to a set of changes provided in the bound variable $changes. Both /inventory and $changes contain a set of part elements, each with a partno and a quantity.

    for $p in /inventory/part
    let $deltap := $changes/part[partno eq $p/partno]
    return 
        replace value of node $p/quantity
        with $p/quantity + $deltap/quantity
    

2.5.2 Typeswitch Expression

The syntax of the typeswitch expression is not changed. Its semantics are extended as follows. Let the expressions in the case and default clauses be called branches. Then:

  1. If the operand expression of a typeswitch is an updating expression, a static error is raised [err:XUST0001].

  2. If any branch is an updating expression, then all branches must be updating or vacuous expressions [err:XUST0001]. In this case, the typeswitch expression is an updating expression.

  3. If all branches are vacuous expressions, the typeswitch expression is a vacuous expression.

  4. Otherwise, the typeswitch expression is a simple expression.

  5. If the typeswitch expression is a simple (including vacuous) expression, its semantics are as specified in Section 3.12.2 TypeswitchXQ.

  6. If the typeswitch expression is an updating expression, then selection of the effective case and binding of variables are performed as specified in Section 3.12.2 TypeswitchXQ. The expression in the return clause of the effective case (or default) is then evaluated, resulting in a pending update list, which serves as the result of the typeswitch expression.

2.5.3 Conditional Expression

The semantics of conditional expressions are extended as follows. Let the expressions in the then and else clauses be called branches. Then:

  1. If the if-clause contains an updating expression, a static error is raised [err:XUST0001].

  2. If either branch is an updating expression, then both branches must be updating or vacuous expressions [err:XUST0001]. In this case, the conditional expression is an updating expression.

  3. If both branches are vacuous expressions, the conditional expression is a vacuous expression.

  4. Otherwise, the conditional expression is a simple expression.

  5. If the conditional expression is a simple (including vacuous) expression, its semantics are as specified in Section 3.10 Conditional ExpressionsXQ.

  6. If the conditional expression is an updating expression, then selection of the effective branch performed as specified in Section 3.10 Conditional ExpressionsXQ. The result of the conditional expression is the pending update list returned by the selected branch.

The following example illustrates the use of updating expressions in a conditional expression:

  • If the element bound to variable $e has a last-updated attribute, update its value to the current date; otherwise insert such an attribute.

    if ($e/@last-updated)
    then replace value of node 
            $e/last-updated with fn:currentDate()
    else insert node 
            attribute last-updated {fn:currentDate()} into $e
    

2.5.4 Comma Expression

The semantics of comma expressions (composed of one or more expressions concatenated by the comma operator, as described in Section 3.3.1 Constructing SequencesXQ) are extended as follows:

  1. If any operand is an updating expression, then all operands must be updating or vacuous expressions [err:XUST0001]. In this case, the comma expression is an updating expression.

  2. If all operands are vacuous expressions, the comma expression is a vacuous expression.

  3. Otherwise, the comma expression is a simple expression.

  4. If the comma expression is a simple (including vacuous) expression, its semantics are as specified in Section 3.3.1 Constructing SequencesXQ.

  5. If the comma expression is an updating expression, its operand expressions are evaluated (in any order), and the pending update lists returned by the operand expressions are merged by the upd:mergeUpdates operation. The resulting merged pending update list is the result of the comma expression.

The following example illustrates the use of an updating comma expression:

  • This example makes the value of an element empty and gives the element an xsi:nil="true" attribute. Both of these operations may be necessary in order to preserve the validity of the element.

    let $q := /inventory/item[serialno = "123456"]/quantity
    return
       ( replace value of node $q with ( ),
         insert node attribute xsi:nil {"true"} into $q )
    

2.5.5 Parenthesized Expression

The semantics of a parenthesized expression (any XQuery expression enclosed in parentheses) are extended as follows:

The category of a parenthesized expression is the same as the category of the expression enclosed in parentheses, which may have any category. The result of a parenthesized expression is also the same as the result of the expression enclosed in parentheses.

An empty parenthesized expression ( ) is a vacuous expression. Its result is an empty sequence and an empty pending update list.

2.5.6 Function Call

The semantics of a function call are extended as follows:

The function call is evaluated as specified in Section 3.1.5 of [XQuery 1.0]. If any input parameter of the function call is an updating expression, a static error is raised [err:XUST0001].

The expression category of a function call is as follows:

2.5.7 Other Expressions

The semantics of all XQuery expressions other than FLWOR expressions, typeswitch expressions, conditional expressions, comma expressions, parenthesized expressions, and function calls are extended as follows:

If any operand of this expression is an updating expression, a static error is raised [err:XUST0001].

In addition, the initializing expression of a variable declaration in a Prolog may not be an updating expression [err:XUST0001].

2.6 Extensions to Built-in Function Library

XQuery Update Facility 1.0 provides extensions to XQuery built-in function library, as specified in this section.

2.6.1 fn:put

fn:put($node as node(), $uri as xs:string) as empty-sequence()

Summary: Stores a document or element to the location specified by $uri. This function is normally invoked to create a resource on an external storage system such as a file system or a database.

The external effects of fn:put are implementation-defined, since they occur outside the domain of XQuery. The intent is that, if fn:put is invoked on a document node and no error is raised, a subsequent query can access the stored document by invoking fn:doc with the same URI.

Semantics:

  1. fn:put is an updating function.

  2. If $node is not a document node or an element node, and the implementation does not support fn:put on the given node kind, a dynamic error is raised [err:FOUP0001].

  3. If $uri is not a valid lexical representation of the xs:anyURI type, a dynamic error is raised [err:FOUP0002]. If $uri is a relative URI reference, it is resolved relative to the value of the base URI property in the static context.

  4. The result of a call to fn:put is an empty XDM instance and a pending update list containing the following update primitive: upd:put($node, $uri).

Notes:

  • The results of fn:put do not become effective until after completion of the current snapshot. The fn:put function has no effect on the set of available documents or collections seen by the current snapshot.

  • If a node that is an operand of fn:put is affected by updating expressions in the current snapshot, the fn:put function operates on the node after these updating expressions are made effective. As a result, after completion of the current snapshot, the effects of updates to $node can be seen via $uri. (For details on application of updates, see [3.2.2 upd:applyUpdates].)

  • If multiple calls to fn:put in the same snapshot operate on the same URI (after any necessary resolution of relative URIs), a dynamic error [err:XUDY0031] is raised. The dynamic error is raised by an expression at some level of the query that contains more than one call to fn:put. For a normative description of this error, see [3.2.1 upd:mergeUpdates] and [3.2.2 upd:applyUpdates].

3 Update Operations

This section describes the update operations defined by XQuery Update Facility 1.0. Although these update operations are described using a functional notation, they are not true functions because many of them have no return value. These update operations are used in defining the semantics of XQuery expressions, but they are not directly available to users.

Update operations consist of update primitives, which are the components of pending update lists, and update routines, which are used in defining XQuery semantics but do not appear on pending update lists.

3.1 Update Primitives

The update primitives described in this section may be held on pending update lists. When an update primitive is held on a pending update list, its node operands are represented by their node identities. The semantics of an update primitive do not become effective until their pending update list is processed by the upd:applyUpdates routine.

3.1.1 upd:insertBefore

Parameters
upd:insertBefore(
   $target as node(),
   $content as node()+)
Summary

Inserts $content immediately before $target.

Constraints

$target must be an element, text, processing instruction, or comment node with a non-empty parent property. $content must be a sequence containing only element, text, processing instruction, and comment nodes.

Semantics
  1. Effects on nodes in $content:

    1. For each node in $content, the parent property is set to parent($target).

    2. If the type-name property of parent($target) is xs:untyped, then upd:setToUntyped() is invoked on each element or attribute node in $content.

  2. Effects on parent($target):

    1. The children property of parent($target) is modified to add the nodes in $content just before $target, preserving their order.

    2. If at least one of the nodes in $content is an element or text node, upd:removeType(parent($target)) is invoked.

3.1.2 upd:insertAfter

Parameters
upd:insertAfter(
   $target as node(),
   $content as node()+)
Summary

Inserts $content immediately after $target.

Constraints

$target must be an element, text, processing instruction, or comment node with a non-empty parent property. $content must be a sequence containing only element, text, processing instruction, and comment nodes.

Semantics

The semantics of upd:insertAfter are identical to the semantics of upd:insertBefore, except that Rule 2a is changed as follows:

  • The children property of parent($target) is modified to add the nodes in $content just after $target, preserving their order.

3.1.3 upd:insertInto

Parameters
upd:insertInto(
   $target as node(),
   $content as node()+)
Summary

Inserts $content as the children of $target, in an implementation-dependent position.

Constraints

$target must be an element or document node. $content must be a sequence containing only element, text, processing instruction, and comment nodes.

Semantics

The semantics of upd:insertInto are identical to the semantics of upd:insertBefore, except that $target is substituted everywhere for parent($target), and Rule 2a is changed as follows:

  • The children property of $target is changed to include the nodes in $content in implementation-dependent positions, preserving their relative order.

3.1.4 upd:insertIntoAsFirst

Parameters
upd:insertIntoAsFirst(
   $target as node(),
   $content as node()+)
Summary

Inserts $content as the first children of $target.

Constraints

$target must be an element or document node. $content must be a sequence containing only element, text, processing instruction, and comment nodes.

Semantics

The semantics of upd:insertIntoAsFirst are identical to the semantics of upd:insertBefore, except that $target is substituted everywhere for parent($target), and Rule 2a is changed as follows:

  • The children property of $target is changed to include the nodes in $content as the first children, preserving their order.

3.1.5 upd:insertIntoAsLast

Parameters
upd:insertIntoAsLast(
   $target as node(),
   $content as node()+)
Summary

Inserts $content as the last children of $target.

Constraints

$target must be an element or document node. $content must be a sequence containing only element, text, processing instruction, and comment nodes.

Semantics

The semantics of upd:insertIntoAsLast are identical to the semantics of upd:insertBefore, except that $target is substituted everywhere for parent($target), and Rule 2a is changed as follows:

  • The children property of $target is changed to include the nodes in $content as the last children, preserving their order.

3.1.6 upd:insertAttributes

Parameters
upd:insertAttributes(
   $target as element(),
   $content as attribute()+)
Summary

Inserts $content as attributes of $target.

Constraints

None

Semantics
  1. For each node $A in $content:

    1. The parent property of $A is set to $target.

    2. If the type-name property of $target is xs:untyped, then upd:setToUntyped($A) is invoked.

  2. The following properties of $target are changed:

    1. attributes: Modified to include the nodes in $content.

    2. namespaces: Modified to include namespace bindings for any attribute namespace prefixes in $content that did not already have bindings.

    3. upd:removeType($target) is invoked.

3.1.7 upd:delete

Parameters
upd:delete(
   $target as node())
Constraints

None

Semantics
  1. If $target has a parent node $P, then:

    1. The parent property of $target is set to empty.

    2. If $target is an attribute node, the attributes property of $P is modified to remove $target.

    3. If $target is a non-attribute node, the children property of $P is modified to remove $target.

    4. If $target is an element, attribute, or text node, and $P is an element node, then upd:removeType($P) is invoked.

  2. If $target has no parent, the XDM instance is unchanged.

Note:

Deleted nodes are detached from their parent nodes; however, a node deletion has no effect on variable bindings or on the set of available documents or collections during processing of the current query.

Note:

Multiple upd:delete operations may be applied to the same node during execution of a query; this is not an error.

3.1.8 upd:replaceNode

Parameters
upd:replaceNode(
   $target as node(),
   $replacement as node()*)
Summary

Replaces $target with $replacement.

Constraints

$target must be a node that has a parent. If $target is an attribute node, $replacement must consist of zero or more attribute nodes. If $target is an element, text, comment, or processing instruction node, $replacement must be consist of zero or more element, text, comment, or processing instruction nodes.

Semantics
  1. Effects on nodes in $replacement:

    1. For each node in $replacement, the parent property is set to parent($target).

    2. If the type-name property of parent($target) is xs:untyped, then upd:setToUntyped() is invoked on each element node in $replacement.

  2. Effect on $target:

    1. The parent property of $target is set to empty.

  3. Effects on parent($target):

    1. If $target is an attribute node, the attributes property of parent($target) is modified by removing $target and adding the nodes in $replacement (if any).

    2. If $target is an attribute node, the namespaces property of parent($target) is modified to include namespace bindings for any attribute namespace prefixes in $replacement that did not already have bindings.

    3. If $target is an element, text, comment, or processing instruction node, the children property of parent($target) is modified by removing $target and adding the nodes in $replacement (if any) in the former position of $target, preserving their order.

    4. If $target or any node in $replacement is an element, attribute, or text node, upd:removeType(parent($target)) is invoked.

3.1.9 upd:replaceValue

Parameters
upd:replaceValue(
   $target as node(),
   $string-value as xs:string)
Summary

Replaces the string value of $target with $string-value.

Constraints

$target must be an attribute, text, comment, or processing instruction node.

Semantics
  1. If $target is an attribute node:

    1. string-value of $target is set to $string-value.

    2. upd:removeType($target) is invoked.

  2. If $target is a text, comment, or processing instruction node: content of $target is set to $string-value.

  3. If $target is a text node that has a parent, upd:removeType(parent($target)) is invoked.

3.1.10 upd:replaceElementContent

Parameters
upd:replaceElementContent(
   $target as element(),
   $text as text()?)
Summary

Replaces the existing children of the element node $target by the optional text node $text. The attributes of $target are not affected.

Constraints

None.

Semantics
  1. For each node $C that is a child of $target, the parent property of $C is set to empty.

  2. The parent property of $text is set to $target.

  3. Effects on $target:

    1. children is set to consist exclusively of $text. If $text is an empty sequence, then $target has no children.

    2. typed-value and string-value are set to the content property of $text. If $text is an empty sequence, then typed-value is an empty sequence and string-value is an empty string.

    3. upd:removeType($target) is invoked.

3.1.11 upd:rename

Parameters
upd:rename(
   $target as node(),
   $newName as xs:QName)
Summary

Changes the node-name of $target to $newName.

Constraints

$target must be an element, attribute, or processing instruction node.

Semantics
  1. If $target is an element node:

    1. node-name of $target is set to $newName.

    2. upd:removeType($target) is invoked.

    3. If $newname has no prefix and no namespace URI, the namespaces property of $target is modified by removing the binding (if any) for the empty prefix.

    4. The namespaces property of $target is modified to include a namespace binding derived from $newName, if this binding did not already exist.

  2. If $target is an attribute node:

    1. node-name of $target is set to $newName.

    2. upd:removeType($target) is invoked.

    3. If $newName is xml:id, the is-id property of $target is set to true.

    4. If $target has a parent, the namespaces property of parent($target) is modified to include a namespace binding derived from $newName, if this binding did not already exist.

  3. If $target is a processing instruction node, its target property is set to the local part of $newName.

Note:

At the end of a snapshot, if multiple attribute nodes with the same parent have the same qualified name, an error will be raised by upd:applyUpdates.

3.1.12 upd:put

Parameters
upd:put(
   $node as node(),
   $uri as xs:string)
Summary

The XDM node tree rooted at $node is stored to the location specified by $uri.

Constraints

$uri must be a valid absolute URI.

Semantics

The external effects of upd:put are implementation-defined, since they occur outside the domain of XQuery. The intent is that, if upd:put is invoked on a document node and no error is raised, a subsequent query can access the stored document by invoking fn:doc with the same URI.

3.2 Update Routines

3.2.1 upd:mergeUpdates

Parameters
upd:mergeUpdates(
   $pul1 as pending-update-list,
   $pul2 as pending-update-list)
Summary

Merges two pending update lists.

Constraints

None.

Semantics
  1. The two pending update lists are merged and a single pending update list containing all the update primitives from both lists is returned.

  2. Optionally, upd:mergeUpdates may raise a dynamic error if any of the following conditions are detected:

    1. Two or more upd:rename primitives on the merged list have the same target node [err:XUDY0015].

    2. Two or more upd:replaceNode primitives on the merged list have the same target node [err:XUDY0016].

    3. Two or more upd:replaceValue primitives on the merged list have the same target node [err:XUDY0017].

    4. Two or more upd:replaceElementContent primitives on the merged list have the same target node [err:XUDY0017].

    5. Two or more upd:put primitives on the merged list have the same $uri operand [err:XUDY0031].

    6. Two or more primitives on the merged list create conflicting namespace bindings for the same element node [err:XUDY0024]. The following kinds of primitives create namespace bindings:

      1. upd:insertAttributes creates one namespace binding on the $target element corresponding to the implied namespace binding of the name of each attribute node in $content.

      2. upd:replaceNode creates one namespace binding on the $target element corresponding to the implied namespace binding of the name of each attribute node in $replacement.

      3. upd:rename creates a namespace binding on $target, or on the parent (if any) of $target if $target is an attribute node, corresponding to the implied namespace binding of $newName.

3.2.2 upd:applyUpdates

Parameters
upd:applyUpdates(
   $pul as pending-update-list,
   $revalidation-mode as xs:string)
Summary

This routine ends a snapshot by making effective the semantics of all the update primitives on a pending update list and by revalidating the resulting XDM instance.

Constraints

$revalidation-mode must be "strict", "lax", or "skip"

Semantics
  1. Checks the update primitives on $pul for compatibility. Raises a dynamic error if any of the following conditions are detected:

    1. Two or more upd:rename primitives on $pul have the same target node [err:XUDY0015].

    2. Two or more upd:replaceNode primitives on $pul have the same target node [err:XUDY0016].

    3. Two or more upd:replaceValue primitives on $pul have the same target node [err:XUDY0017].

    4. Two or more upd:replaceElementContent primitives on $pul have the same target node [err:XUDY0017].

    5. Two or more upd:put primitives on the merged list have the same $uri operand [err:XUDY0031].

    6. Two or more primitives on $pul create conflicting namespace bindings for the same element node [err:XUDY0024]. The following kinds of primitives create namespace bindings:

      1. upd:insertAttributes creates one namespace binding on the $target element corresponding to the implied namespace binding of the name of each attribute node in $content.

      2. upd:replaceNode creates one namespace binding on the $target element corresponding to the implied namespace binding of the name of each attribute node in $replacement.

      3. upd:rename creates a namespace binding on $target, or on the parent (if any) of $target if $target is an attribute node, corresponding to the implied namespace binding of $newName.

  2. The semantics of all update primitives on $pul, other than upd:put primitives, are made effective in the following order:

    1. First, all upd:insertInto, upd:insertAttributes, upd:replaceValue, and upd:rename primitives are applied.

    2. Next, all upd:insertBefore, upd:insertAfter, upd:insertIntoAsFirst, and upd:insertIntoAsLast primitives are applied.

    3. Next, all upd:replaceNode primitives are applied.

    4. Next, all upd:replaceElementContent primitives are applied.

    5. Next, all upd:delete primitives are applied.

  3. If, as a net result of the above steps, the children property of some node contains adjacent text nodes, these adjacent text nodes are merged into a single text node. The string-value of the resulting text node is the concatenated string-values of the adjacent text nodes, with no intervening space added. The node identity of the resulting tex