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 the First
Public 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 document has been produced by the
XML Query Working Group
(part of the XML Activity),
following the procedures set out in the
W3C Process Document.
The XML Query Working Group feels that the contents of this
Working Draft are relatively stable, and therefore encourages feedback on this version.
These Requirements identify extensions to the
XQuery 1.0 Recommendation published 23 January 2007
to make it functional as a scripting language.
That capability has been requested by WG participants and
has been encouraged by members of the larger community
who do not participate in the W3C activities.
The XML Query WG has reviewed these requirements and has
reached a high level of agreement (but not necessarily unanimity) on
the desirability of each of them.
Public comments on this document and its open issues are invited.
Comments on this document should be made in W3C's
public Bugzilla system
(instructions can be found at
http://www.w3.org/XML/2005/04/qt-bugzilla).
When entering comments, select the Product named "XPath / XQuery / XSLT",
the Component named "XQuery Scripting Extensions Requirements",
and the Version named "Working drafts".
This repository includes open issues recorded by the
XML Query Working Group as well as by members of the public.
If access to the Bugzilla system is not feasible, you may send
your comments to the W3C XSLT/XPath/XQuery mailing list,
public-qt-comments@w3.org.
It will be very helpful if you include the string [ScriptReq]
in the subject line of your comment, whether made in Bugzilla or in email.
Each Bugzilla entry and email message should contain only one comment.
Archives of the comments and responses are available at
http://lists.w3.org/Archives/Public/public-qt-comments/.
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.
1 Goals
This document describes the requirements for the XQuery Scripting
Extensions.
XQuery [XQuery 1.0]
is a functional language that is Turing-complete and well suited
to write code that ranges from simple queries to complete
applications. However, some categories of applications are more easily
implemented by combining XQuery
capabilities with some imperative
features, such as the ability to explicitly manage internal
states. The same issue stands for XQuery
enriched with the [XQuery Update Facility]
(hereafter,
XQuery With Updates).
The scripting extension is intended to overcome this problem, and allow
programmers to write such applications without relying on embedding
XQuery into an external language.
2 Usage Scenarios
The following usage scenarios describe ways in which the
XQuery Scripting Extension 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 Scripting Extension, 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.
While XQuery is very well suited to
perform the main tasks of XML exploration and transformation that are
common to most of these cases, some limited extensions would make it
easier to use XQuery to write some complex
applications that belong to the following usage scenarios.
- Applications that perform complex manipulations on
persistent XML data
Writing applications that modify persistent data,
stored in files or in databases. Such applications may
need to operate on data in stages, and may need to verify
that the modified data meet some constraints.
- Complex XML to XML transformations
Writing code that performs complex XML to XML transformations.
- Implementation of web services
Writing code that implements a web service, with the
ability to access and modify persistent XML data.
- Processing RSS feeds
Writing code that generates or aggregates RSS feeds.
- Web service message composition and orchestration
Writing code that orchestrates web services.
- XML application integration
Writing scripting code that calls both
XQuery
With
Updates and external
functions, which may manipulate state and perform
side-effects.
- XML data cleaning or normalization
Writing code that performs data cleaning
operations.
- XML data integration
Writing code that accesses multiple data sources with
the ability of reflecting updates from the integrated data
to the data sources.
- XML data verification
Expressing complex constraints on XML data.
3 Requirements
3.1 Terminology
In this specification the words
must,
must not,
should,
should not,
may
and
recommended, when
are to be interpreted as described in [RFC 2119].
When these words
are used in this technical sense, they occur as a hyperlink to [RFC 2119]. These words will also be used with their conventional English
meaning, in which case there is no hyperlink.
- XQuery With Updates
This term identifies
XQuery
extended with the
[XQuery Update Facility].
- Side-effects
We say that an expression has side-effects if its evaluation may affect the external environment or may affect the result of the subsequent evaluation of another expression.
3.2 General Requirements
- Compatibility with other extensions
The XQuery Scripting Extension
must
not
preclude the use of the
other XQuery extensions developed by the Working Group.
- Protocol Independence
The XQuery Scripting Extension
must
be defined independently
of any protocols with which it is used.
- Language Syntax
The XQuery Scripting Extension must 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.
- Static Type Checking
The XQuery Scripting Extension
should
provide an optional
static type checking feature.
- Ease of programming
The XQuery Scripting Extension
may
include syntactic
constructs to facilitate common programming tasks.
3.3 Relationship to XQuery
- Based on Data Model
The XQuery Scripting Extension must
be defined on the [XQuery 1.0 and XPath 2.0 Data Model].
- Based on XQuery
The XQuery Scripting Extension must be based on XQuery. The Scripting Extension may constrain the evaluation order more than XQuery evaluation model, but the evaluation of an expression that belongs to the syntax of XQuery must result in a value, or in an error, that is one of those allowed by
XQuery
semantics.
- Based on XQuery With Updates
The XQuery Scripting Extension
should be based on
XQuery With Updates.
If it is based on XQuery With Updates,
it may constrain the evaluation order in ways that are not required by
XQuery With Updates evaluation model. However,
if both
XQuery With Updates
and the XQuery Scripting Extension specify a result value for a given expression,
they must specify the same result value.
- Optimization
The XQuery Scripting Extension should be designed in such a way that the ability of a processor to optimize queries or parts of a query that make no use of the extension is not compromised.
3.4 Functionalities
- Controlling the order of evaluation of functions
and expressions that have side-effects
It must be possible for the
programmer to control the evaluation order of expressions and function
calls that perform side-effects.
- Preserving state during computation
It must be possible to write code where pieces of data are bound to
variables which are passed to further stages of the computation, and it
must be possible to modify the value associated to such variables.
- Returning values from expressions that have side-effects
It must be possible to write code that has side-effects and returns a value.
- Ability to see side-effects during computation
It must
be possible for an expression to observe some side-effects caused by other expressions.
- Error handling
It must be possible to control
error propagation and to perform
alternative actions when the evaluation of an expression raises an error.
- Controlling the scope of snapshot, isolation, atomicity
The extension may provide the
ability to control the scope of snapshots.
The extension may provide the
ability to identify pieces of code whose execution should be isolated
from the outer environment. It
may be possible
to indicate that some pieces of code must be executed atomically, with
respect to failures.