W3C home > Mailing lists > Public > www-xml-query-comments@w3.org > July 2001

Re: Working draft of XQuery

From: Jerome Simeon <simeon@research.bell-labs.com>
Date: Mon, 9 Jul 2001 09:43:17 -0400
Message-ID: <15177.46325.881015.555146@starling.research.bell-labs.com>
To: aayad@us.ibm.com
Cc: www-ql@w3.org, www-xml-query-comments@w3.org

Dear Ahmed,

This is a response to the following message, which you posted to the
W3C query languages mailing list:

http://lists.w3.org/Archives/Public/www-ql/2001AprJun/0032.html

There are two distinct questions in your message.

-------

The first question is why does the XML Query working group care about
static typing?  There are many good reasons to be concerned about
static typing for XQuery:

 - static typing allows to detect many common errors at compile
   time. For example:

   o that the query applies string concatenation on something
     different than a string;
   o to detect when a path expression accesses elements or attributes
     that do not exist;
   o etc.

   Detecting errors early-on reduces the amount of debugging to
   perform at run time. It also facilitates the generation of error
   messages that points directly to the reason of the error.

 - static typing allows to make sure that the result of a query will
   comply to a given Schema. For example:

    o one might want to verify that a query generates valid VoiceXML
      in order to export to a voice interface.
    o In data exchange scenarios, partners will agree to both generate
      and process XML documents (e.g., purchase orders in cXML). This
      decision might even be made contractual.
    o etc.

   Being able to statically verify that the result of a query complies
   to that schema provides important safety guarantees. Furthermore,
   it removes the need to validate each documents individually, which
   brings obviously a big performance improvement.

 - type inference is a big help during the development
   process. Whenever a query compiles, the type system of the XML Core
   (former XML Query Algebra) returns the type of the resulting
   expression inferred by the system. The developer can then check if
   the type returned is indeed the type he expected, which is an
   important validity check on the semantics of the query. For
   example:

   o Assuming the developer wants to access the title and publisher
     of books, if he makes a mistakes and accesses the editor instead
     of the publisher, the type inferred will differ from the type he
     expects.  He can then modify his query accordingly.
   o Assuming he wants to get the first section of a book, but he
     forgets the [1] XPath qualifier, the type system will tell him
     his query returns a collection of books instead of a single
     book. He can then modify his query accordingly.
   o etc.

 - finally, many believe that typing will play an important role in
   the development of efficient implementations of XQuery.

For all these reasons, the XML Query working group considers static
typing has a highly valuable feature for XQuery and his users.

The way typing is done by XQuery is by developing a type inference
system for the XQuery Core (former XML Query Algebra). Doing the
typing at the core level simplifies the task tremendously, as typing
needs only to be defined for a small set of operations. This would be
much harder to define it for the full XQuery syntax. Mapping XQuery to
the core then results in a full type inference system for XQuery.

-------

The second question is why isn't the XML Query working group spending
time working on algebraic optimizations.

The XML Query working group is very aware of the importance of query
optimization for users, but we do not believe it is the direct task of
the group to propose standard optimizations.

Still, query optimization has been very much taken into account in the
design of XQuery. Indeed requirement [3.2.2 Declarativity] in the XML
Query Requirements document [1] is related to the ability to support
some forms of optimization. Also, the XQuery 1.0 Formal Semantics
contains a number of algebraic rewritings [2] that suggest that many
traditional optimizations should be possible with XQuery.

The XML Query working group strongly believes that the design of the
language will make it susceptible to query optimization. Actual
implementation of XQuery, and specific optimizations will be left to
individual companies and developers.

We appreciate your feedback on the XML Query specifications.  Please
let us know if this response is satisfactory. If not, please respond
to this message, explaining your concerns.

Jerome Simeon
On behalf of the XML Query Working Group.


References:

[1] XML Query Requirements
http://www.w3.org/TR/xmlquery-req

[2] XQuery 1.0 Formal Semantics
http://www.w3.org/TR/query-algebra/#sec_equivlaws


aayad@us.ibm.com writes:
 > Hi,
 > 
 > > >Good! This is Subject: what I was hoping for :-)
 > > >I also hope that there will be only one type system for xquery and the
 > > >algebra.
 > 
 > >  Certainly. Since the algebra defines the type system for XQuery, the
 > > language can not have a separate type system.
 > 
 > > Jonathan
 > 
 > Regarding the subject of type systems, I am curious about the reason to be
 > concerned about strongly typing the algebra. From what I understand, the
 > algebra's job is to accurately and un-ambiguously express the *operations*
 > and the outcome of a certain query. So, why complicate the algebra by a
 > type system. Clearly, nobody is going to use the algebra as its query
 > language, rather, it will merely be used to represent queries issued in an
 > XML query language (like XQuery). So, why not leave the task of
 > statically/dynamically checking the type of the inputs and outputs to the
 > query processors and focus in the algebra on the equivalence rules and
 > transformations. These are the important subject of the algebra *real*
 > users - the query optimizers.
 > 
 > best regards,
 > Ahmed.
Received on Monday, 9 July 2001 09:45:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 2 February 2007 00:13:02 GMT