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.
XML Representation
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.
Programmatic Manipulation
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".
Contact Information:
Peter Laird
Quark, Inc.
plaird@quark.com