W3C

XQuery Update Facility Requirements

W3C Working Draft 3 June 2005

This version:
http://www.w3.org/TR/2005/WD-xquery-update-requirements-20050603/
Latest version:
http://www.w3.org/TR/xquery-update-requirements/
Previous version:
http://www.w3.org/TR/2005/WD-xquery-update-requirements-20050211/
Editors:
Don Chamberlin, IBM Almaden Research Center <chamberlin@almaden.ibm.com>
Jonathan Robie, DataDirect Technologies <jonathan.robie@datadirect.com>

Abstract

This document specifies goals and requirements for the XQuery Update Facility.

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

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.

The XQuery Update Facility has been defined by the XML Query Working Group (part of the XML Activity). It is designed to be read in conjunction with [XQuery 1.0].

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, public-qt-comments@w3.org (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.

Table of Contents

1 Goals
2 Usage Scenarios
3 Requirements
    3.1 Terminology
    3.2 General Requirements
    3.3 Relationship to XQuery 1.0
    3.4 XML Query Update Functionality
    3.5 Transaction characteristics

Appendix

A References


1 Goals

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.

2 Usage Scenarios

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.

Updating persistent XML stores

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

Modify XML messages to change status and add information created while processing the message.

Add to existing XML document

Add new data to an existing XML document; for instance, add a new entry to a BLOG or a data log.

Updating XML registries

Perform updates on configuration files, user profiles, or administrative logs represented in XML.

Creating edited copies

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

Modifying XML views of non-XML sources, such as a [SQL/XML] view of a SQL database.

3 Requirements

3.1 Terminology

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:

MUST

This word means that the item is an absolute requirement.

SHOULD

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.

MAY

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.

3.2 General Requirements

Query Update Syntax

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.

Declarativity

The XQuery Update Facility MUST be declarative. Notably, it MUST be independent of any particular evaluation strategy.

Protocol Independence

The XQuery Update Facility MUST be defined independently of any protocols with which it is used.

Error Conditions

The XQuery Update Facility MUST define standard error conditions that can occur during the execution of an update.

Static Type Checking

The XQuery Update Facility SHOULD provide an optional static type checking feature.

3.3 Relationship to XQuery 1.0

Based on Data Model

The XQuery Update Facility MUST be defined on the [XQuery 1.0 and XPath 2.0 Data Model].

Note:

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.

Based on XQuery

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.

3.4 XML Query Update Functionality

Locus of modifications

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.

Delete

The XQuery Update Facility MUST be able to delete nodes.

Insert

The XQuery Update Facility MUST be able to insert new nodes in specified positions.

Replace

The XQuery Update Facility MUST be able to replace a node.

Changing values

The XQuery Update Facility MUST be able to change the value returned by the typed-value accessor for a node.

Modifying properties

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.

Moving nodes

The XQuery Update Facility MAY be able to move a node from one location to another.

Conditional updates

The XQuery Update Facility MUST be able to do conditional updates.

Iterative updates

The XQuery Update Facility MUST be able to iterate over nodes to do updates.

Validation

The XQuery Update Facility MAY support an explicit XML Schema validation operation that preserves node identity.

Note:

The XQuery validate expression creates a new copy of each validated node, with a new identity.

Compositionality

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.

Parameterization

The XQuery Update Facility SHOULD provide a means to parameterize update operations.

3.5 Transaction characteristics

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

Atomicity

The XQuery Update Facility MUST provide a set of atomic operations, and MUST define a means to group atomic operations into an atomic execution unit.

Consistency

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.

Isolation

The XQuery Update Facility SHOULD define the means by which operations can be isolated from concurrent operations.

Durability

The XQuery Update Facility MUST define a means to control the durability of atomic operations and atomic execution units.

A References

Transaction Processing Concepts and Techniques
Gray, J. and Reuter, A. 1994. Transaction Processing Concepts and Techniques. Morgan Kaufmann Publishers, San Mateo, CA
SQL/XML
International Organization for Standardization (ISO). ISO/IEC 9075-14:2003, Information Technology - Database Languages - SQL - Part 14, XML-Related Specifications (SQL/XML). (Available from American National Standards Institute, New York, NY 10036, (212) 642-4900.)
XQuery 1.0 and XPath 2.0 Data Model
World Wide Web Consortium. XQuery 1.0 and XPath 2.0 Data Model. W3C Working Draft, 29 Oct 2004. See http://www.w3.org/TR/xpath-datamodel/.
XQuery 1.0
World Wide Web Consortium. XQuery 1.0. W3C Working Draft, 29 Oct 2004. See http://www.w3.org/TR/xquery/.