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/.
This is a public W3C Working Draft for review by W3C Members and other interested parties. Publication as a Working Draft 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 is a re-publication of the first public Working Draft of these requirements. This re-publication clarifies that the WG does not intend to produce a Recommendation from this Working Draft. Comments on this document are invited. Comments should be sent to the W3C XML Query and XSL Transformations mailing list, email@example.com (archived at http://lists.w3.org/Archives/Public/public-qt-comments/). The string "[Update]" (including the square brackets, but not the quotation marks) should appear as the first characters in the Subject field of such comments.
As of this publication, the Working Group expects to eventually publish this document as a Working Group Note. It is not expected to become a W3C Recommendation, and therefore it has no associated W3C Patent Policy licensing obligations.
This document describes the requirements for the XQuery Update Facility. [XQuery 1.0] provides queries, but has no support for adding new values or changing existing values. The XML Query Working Group intends to add support for updates in a future version of XQuery.
The following usage scenarios describe how the XQuery Update Facility may be used in various environments, and represent a wide range of activities and needs that illustrate the problem space to be addressed. They are intended to be used as design cases during the development of the XQuery Update Facility, and should be reviewed when critical decisions are made. These usage scenarios should also prove useful in helping non-members of the XML Query Working Group understand the intent and goals of the project.
Modify XML in persistent XML stores, including native XML databases, XML files stored on a file system, or XML stored in SQL databases.
Modify XML messages to change status and add information created while processing the message.
Add new data to an existing XML document; for instance, add a new entry to a BLOG or a data log.
Perform updates on configuration files, user profiles, or administrative logs represented in XML.
Create a new copy of an XML document or subtree that differs from the original in the way specified by the update. For instance, updates could be used to modify a web message in order to add new information and change headers to reflect the modified status.
Modifying XML views of non-XML sources, such as a [SQL/XML] view of a SQL database.
The following key words are used throughout the document to specify the extent to which an item is a requirement for the work of the XML Query Working Group:
This word means that the item is an absolute requirement.
This word means that there may exist valid reasons not to treat this item as a requirement, but the full implications should be understood and the case carefully weighed before discarding this item.
This word means that an item deserves attention, but further study is needed to determine whether the item should be treated as a requirement.
When the words MUST, SHOULD, or MAY are used in this technical sense, they occur as a hyperlink to these definitions. These words will also be used with their conventional English meaning, in which case there is no hyperlink. For instance, the phrase "the full implications should be understood" uses the word "should" in its conventional English sense, and therefore occurs without the hyperlink.
The syntax for updates MAY have more than one syntax binding. One syntax MUST be convenient for humans to read and write. One syntax MUST be expressed in XML in a way that reflects the underlying structure of the operations.
The XQuery Update Facility MUST be defined independently of any protocols with which it is used.
The XQuery Update Facility MUST define standard error conditions that can occur during the execution of an update.
The XQuery Update Facility SHOULD provide an optional static type checking feature.
The properties of a Data Model instance that can be modified by the XQuery Update Facility are discussed in 3.4 XML Query Update Functionality.
The XQuery Update Facility MUSTbe based on [XQuery 1.0]. The XQuery Update Facility MUSTuse XQuery to identify items to be updated. The XQuery Update Facility MUST use XQuery to specify items used in the updates.
The XQuery Update Facility MUST be able to change the properties of existing nodes while preserving their identity. The XQuery Update Facility MUST be able to create a new copy of a node with a specific set of changes.
The XQuery Update Facility MUST be able to delete nodes.
The XQuery Update Facility MUST be able to insert new nodes in specified positions.
The XQuery Update Facility MUST be able to replace a node.
The XQuery Update Facility MUST be able to change the value returned by the typed-value accessor for a node.
The XQuery Update Facility SHOULD be able to modify some of the properties of a node such as the name, type, content, nilability, base-URI, etc.
The XQuery Update Facility MAY be able to move a node from one location to another.
The XQuery Update Facility MUST be able to do conditional updates.
The XQuery Update Facility MUST be able to iterate over nodes to do updates.
The XQuery Update Facility MAY support an explicit XML Schema validation operation that preserves node identity.
The XQuery validate expression creates a new copy of each validated node, with a new identity.
The XQuery Update Facility MUST be able to compose update operators with other update operators. The XQuery Update Facility MAY be compositional with respect to XQuery expressions; that is, it may be possible to use an update wherever an XQuery expression is used.
The XQuery Update Facility SHOULD provide a means to parameterize update operations.
In this section, the terms Atomicity, Consistency, Isolation, and Durability are taken from the ACID model of transaction characteristics for databases, which is described in [Transaction Processing Concepts and Techniques].
At the end of an outermost update operation (that is, an update operation invoked from the external environment), the data model MUST be consistent with respect to the constraints specified in the Data Model. In particular, all type annotations MUSTbe consistent with the content of the items they govern. The XQuery Update Facility MAY define additional levels of granularity at which Data Model constraints are enforced.
The XQuery Update Facility SHOULD define the means by which operations can be isolated from concurrent operations.
The XQuery Update Facility MUST define a means to control the durability of atomic operations and atomic execution units.