This paper lacks a specific position with regard to XML QL, but rather contains a set of guidelines by which we will evaluate differing proposals. Instead of presenting implementation specifics for our vision of an XML query language, we prefer instead to list the features upon which we will rely.
Quark product users are generally aligned into two categories: 1) the small shop users with little need for automated job tracking, and 2) the large publication sites with extensive data storage and retrieval systems. It is the second class of customers that seem to have the highest need for a document workflow that includes XML. Therefore, our requirements for XML QL are derived mostly from the needs of those large sites.
Some big generalizations can be made about large publication sites:
The first generalization requires that Quark provide a GUI for query operations. Therefore, we are not deeply concerned about the simplicity of the query language because it will be computer generated (with rare exceptions). Also, the complexity of the average query will be low, which eliminates the need for the more exotic features of the query language. The second generalization obviates the need for Quark to provide extensive document fragment functionality. The third generalization emphasizes the static nature of the structure of the content at these sites.
The favorite phrase of a fellow programmer is:
"Good programmers imitate, great programmers steal."
In this spirit, I have parsed other position papers for this conference and shamelessly stole pieces that seem most relevant to Quark. Once again, we are interested more in features than syntax.
Italicized text represents comments added by me.
Exploit Available Schema
Conversely, when DTDs are available for a data source, it should be possible to judge whether an XQuery is correctly formed relative to the DTDs, and to calculate a DTD for the output. This capability can detect errors at compile time rather than run time, and allows a simpler interface for applications to manipulate a query result. Yes. If we allow users to write free form queries, this will be essential. We cannot expect them to debug their queries, we need to do that for them through validation.
An XQuery should be representable in XML. While there may be more than one syntax for XQuery, one should be as XML data. (Note that XSL is written in XML.) This property means that there do not need to be special mechanisms to store and transport XQueries, beyond what is required for XML itself. It also helps satisfy Requirement 2.7. Yes, it is convenient.
XQueries should be amenable to creation and manipulation by programs. Most queries will not be written directly by users or programmers. Rather, they will be constructed through user-interfaces or tools in application development environments. Yes!
Support for New Datatypes
XQuery should have an extension mechanism for conditions and operations specific to a particular datatypes. I am thinking mainly of specialized operations for selecting different kinds of multimedia content. Yes, but how?
Uniform treatment of attributes and elements.
XML has two different syntaxes which are often used equivalently: attributes specified in the tags, and nested elements. A number of XML dialect proposals treat these as equivalent. We would therefore like a query language which also did so. Obviously, attributes can not be nested. Yes.
XQL queries may return any number of results, including 0. Yes. It would also be nice to limit the number of returns, like "give me first 5 results" or "give me the first one you find".