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 https://www.w3.org/TR/.
This document is governed by the 1 March 2017 W3C Process Document.
This Working Group Note has been published in order to document the work that the XML Query Working Group has done in the area of providing an imperative extension to XQuery. The WG was unable to achieve consensus on several significant aspects of this technology and determined to terminate work on the project in mid-2014.
Please report errors in this document using W3C's public Bugzilla system (instructions can be found at https://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, email@example.com. It will be very helpful if you include the string “[SXReq]” 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 https://lists.w3.org/Archives/Public/public-qt-comments/.
Publication as a Working Group Note 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.
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 1.0] (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.