| The XML Query Working Group did not draw up a formal list of the principles that guided the design of XQuery. Nevertheless, throughout the design process, a reasonably stable consensus existed in the working group about at least some of the principles that should underlie the design of an XML query language. Some of these principles were mandated by the charter of the working group, and others arose from strongly held convictions of its members . The following list is my own attempt to enumerate the basic ideas and principles that were most influential in shaping the XQuery language. Tension exists among some of these principles, and several design decisions were the result of an attempt to find a reasonable compromise among conflicting principles. -
Compositionality : Perhaps the longest-standing principle in the design of XQuery is that XQuery should be a functional language incorporating the principle of compositionality . This means that XQuery consists of several kinds of expressions, such as path expressions, conditional expressions, and element constructors, that can be composed with full generality. The result of any expression can be used as the operand of another expression. No syntactic constraints are imposed on the ways in which expressions can be composed (though the language does have some semantic constraints ). Each expression returns a value that depends only on the operands of the expression, and no expression has any side effects. The value returned by the outermost expression in a query is the result of the query. -
Closure : XQuery is defined as a transformation on a data model called the Query data model . The input and output of every query or subexpression within a query each form an instance of the Query data model. This is what is meant by the statement that XQuery is closed under the Query data model. The working group spent considerable time on the definition of the Query data model and on how instances of this model can be constructed from input XML documents and/or serialized in the form of output XML documents. -
Schema conformance : Since XML Schema has recently been adopted as a W3C Recommendation, the working group considered it highly desirable for XQuery to be based on the type system of XML Schema. This constraint strongly influenced the design of XQuery by providing a set of primitive types , a type-definition facility, and an inheritance mechanism. The validation process defined by XML Schema also strongly influenced the XQuery facilities for constructing new elements and assigning their types. Nevertheless, members of the working group attempted to modularize the parts of the language that are related to type definition and validation, so that XQuery could potentially be used with an alternative schema language at some future time. -
XPath compatibility : Because of the widespread usage of XPath in the XML community, a strong effort was made to maintain compatibility between XQuery and XPath Version 1.0. Despite the importance of this goal, it was necessary in a few areas to compromise compatibility in order to conform to the type system of XML Schema, because the design of XPath Version 1.0 was based on a much simpler type system. -
Simplicity : Many members of the working group considered simplicity of expression and ease of understanding to be primary goals of our language design. These goals were often in conflict with other goals, resulting in some painful compromises. -
Completeness : The working group attempted to design a language that would be complete enough to express a broad range of queries. The existence of a well-motivated use case was considered a strong argument for inclusion of a language feature. The expressive power of XQuery is comparable to the criterion of "relational completeness" defined for database query languages [CODD], though no such formal standard has been defined for an XML data model. Informally, XQuery is designed to be able to construct any XML document that can be computed from input XML documents using the power of the first-order predicate calculus. In addition, recursive functions add significant expressive power to the language. -
Generality : XQuery is intended for use in many different environments and with many kinds of input documents. The language should be applicable to documents that are described by a schema, or by a Document Type Definition [XML], or by neither . It should be usable in strongly typed environments where input and output types are well known and rigorously enforced, as well as in more dynamic environments where input and output types may be discovered at execution time and some data may be untyped. It should accommodate input documents from a variety of sources, including XML files discovered on the Web, repositories of pre- validated XML documents, streaming data sources such as stock tickers, and XML data synthesized from databases. -
Conciseness : In the interest of conciseness, the semantics of the XQuery operators were defined to include certain implicit operations. For example, arithmetic operators such as + , when applied to an element, automatically extract the numeric value of the element. Similarly, comparison operators such as = , when applied to sequences of values, automatically iterate over the sequences, looking for a pair of values that satisfies the comparison (this process is called existential quantification ). These implicit operations are consistent with XPath Version 1.0 and were preferred over a design that would require each operation to be explicitly specified by the user . -
Static analysis : From the beginning, the processing of a query was assumed to consist of two phases, called query analysis and query evaluation ( roughly corresponding to compilation and execution of a program.) The analysis phase was viewed as an opportunity to perform optimization and to detect certain kinds of errors. A great deal of effort went into defining the kinds of checks that could be performed during the analysis phase and in deciding which of these checks should be required and which should be permitted.  |
