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, email@example.com. 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.
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.
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.
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.
Writing code that performs complex XML to XML transformations.
Writing code that implements a web service, with the ability to access and modify persistent XML data.
Writing code that generates or aggregates RSS feeds.
Writing code that orchestrates web services.
Writing code that performs data cleaning operations.
Writing code that accesses multiple data sources with the ability of reflecting updates from the integrated data to the data sources.
Expressing complex constraints on XML data.
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.
The XQuery Scripting Extension must not preclude the use of the other XQuery extensions developed by the Working Group.
The XQuery Scripting Extension must be defined independently of any protocols with which it is used.
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.
The XQuery Scripting Extension should provide an optional static type checking feature.
The XQuery Scripting Extension may include syntactic constructs to facilitate common programming tasks.
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.
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.
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.
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.
It must be possible to control error propagation and to perform alternative actions when the evaluation of an expression raises an error.
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.