This chapter is from the book
This chapter is from the book
This chapter is from the book
Conclusion
The design of XQuery has been a process of resolving the tensions between conflicting goals. It has been a slow process, and compromise has frequently been necessary.
The designers of XQuery did not begin with a blank slate. The Query data model was largely dictated by XML itself and by related W3C Recommendations such as XML Namespaces. The design of the language was also constrained by compatibility with existing standards such as XPath and XML Schema. Reconciling these constraints was not straightforward—for example, XPath Version 1 has only four types and a rather loose set of rules for type conversions, whereas XML Schema has forty-four built-in atomic types, a complex syntax for defining new types, and a strict set of rules for type validation.
As a general-purpose query language, XQuery needs to support a variety of usage modes. It needs to operate on untyped documents as well as on documents that are described by schemas and by DTDs. It needs to operate on individual XML files, on large repositories of pre-validated documents, on XML data synthesized from sources such as relational databases, and on streaming XML data. It needs to support applications in which all types are known and static typing guarantees are important, as well as exploratory queries in which the expected type of the result is not known in advance. It needs to support precise and reproducible queries as well as approximate searches, such as searches for synonyms of a given word. In order to span these modes of use while keeping the entry cost of an implementation as low as possible, the working group organized XQuery as a basic language and a set of optional features.
The Query working group did not conduct its work in isolation. All changes to XPath were discussed and approved jointly by the Query working group and the XSLT working group, since XPath is embedded in both the XQuery and XSLT languages. The Query working group consulted frequently with the Schema working group on issues such as date/time arithmetic, which required two new subtypes to be derived from the duration type. Internationalization aspects of XQuery were designed in cooperation with the Internationalization (I18N) working group. Suggestions on XQuery requirements and features were received from other working groups and individuals from time to time.
During the design of XQuery, the working group typically had a membership of between thirty and forty members, representing around twenty-five companies. These representatives formed a diverse group, with backgrounds ranging from relational database management to library science, and included the designers of several query languages. Some were theoretical in their orientation, and others were more pragmatic. Some represented software vendors and some represented the user community. The world's largest software companies were represented, as were several new startup companies.
The working group conducted weekly conference calls and held a face-to-face meeting about every six weeks. Subgroups were formed to deal with specialized topics such as full-text search and the core function library. As is customary in the W3C, the working group operated by a process of consensus building, in which design alternatives were explored and decisions were made only after a consensus was reached (as determined by the chair). Design progress was documented in a series of working drafts that described the language in general, the data model, the function library, the formal semantics of the language, and a set of use cases. Each of these working drafts was republished on the working group web page about every three months. Throughout this process, public feedback was invited, and the members of the working group responded to public comments in online forums. At all times, the working group maintained a prototype parser based on the latest XQuery grammar.
At the time of this writing, the broad outline of XQuery Version 1 is reasonably stable, and the working group is engaged in editing the details of the language specification. Because of a strong desire to publish a stable recommendation as soon as possible, it is likely that several important features will not be included in XQuery Version 1. Examples include an update facility, text search features such as stem-matching and relevance ranking, a view definition facility, and bindings to specific host languages such as Java. These features are strong candidates for inclusion in a future version of XQuery.
The design process used by the Query working group is probably not the fastest way to design a query language, and languages designed by large committees are not often noted for elegance and simplicity. Nevertheless, the members of the working group hope that their diverse backgrounds and interests have contributed to making XQuery robust for a broad spectrum of usage environments. Time and experience will provide a measure of their success.