W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2002

Response to Tim Bray's comment "PSVI Considered Dangerous"

From: Ashok Malhotra <ashokma@microsoft.com>
Date: Wed, 18 Sep 2002 15:40:34 -0400 (EDT)
Message-ID: <E5B814702B65CB4DA51644580E4853FB03DA7349@red-msg-12.redmond.corp.microsoft.com>
To: <tbray@textuality.com>, "Paul Cotton" <pcotton@microsoft.com>
Cc: "XQuery Comments" <public-qt-comments@w3.org>
Tim:
This is an official response from the XML Query WG to your comment
"TB 8" raised in [1].  This email does not address any of the other
comments in that email.

========================================================================
In his comment Tim voices concern that XQuery is dependent on XML
Schema, both because of the size and complexity of XML Schema, and
because of the potential that the use of other schema languages will
make interoperability of XQuery problematic.  We respond to these
comments
below.

First of all, XQuery must have a type system of some sort.  The
semantics of the language are defined in terms of the type system: it
determines the types of legal operands to operations and functions, and
how the type of the result of an operation or function is determined.
The type system also determines explicit and implicit casting rules.
This is true not only of XQuery, of course, but of any typed query or
programming language.

XQuery made the decision to support XML Schema, in spite of the
complexity that implied.  Our choice was made for several reasons:
* there was strong W3C guidance in favor of re-use 
        between the different working groups and recommendations,
	* the belief that many (most) of the information that would 
	  be queried would be typed by XML Schema.   
	* the belief that we would better support interoperability if we

        avoided the temptation to do our own language,
		* and the belief that a tight coupling with XML Schema
would, in 
        fact, benefit both standards. 

It is worth expanding on the last point: there are features of XML
Schema that may or may not become widely used; surely this will be
influenced, in part, by whether or not other tools can respect and
exploit them. While this is clearly a decision for the Architecture
team, we feel rather strongly that both XQuery and XML Schema are made
more effective by mutual support, and that lack of support for XML
Schema features in XQuery can only hurt XML Schema acceptance and use.

Also let it be said that during most of XQuery's design period there was
only one viable schema language available.  Even today, while RELAX NG
has gained some popularity, XML Schema continues to be the primary
schema language with some persisting use of DTDs and XDR.

However, that said, there are some caveats to this main decision:
	* We have "cheated" in some places, simplifying the type system 
        we use relative to XML Schema.  For example, XQuery does not 
        support minOccurs/maxOccurs.  We have attempted to choose these 
        variances or simplifications of XML Schema carefully, where 
	  they simplified XQuery without, we hope, serious loss of
value.
	* We have designed the language so that a schema is not
required, 
	  by carefully defining the contents of a data model and type 
	  annotations so that they could be constructed without the use 
	  of a schema, and by providing a conformance level that makes 
	  no use of XML Schema other than the primitive types.
	* We have always assumed that it would be possible to "import" 
	  other kinds of schemas, if their type information could be 
	  mapped onto the type information that we require.  This, for 
	  example, is how we envision support for DTD's.  The burden, 
	  however, of performing this mapping should be on the vendors 
	  and/or organizations that wish to use other schema languages, 
		  not on this working group.  It should be noted that
the 
		  integration of types from two different system is a
very   
		  difficult problem.              
    
As an illustration of this last point, consider RELAX NG:  RELAX NG does
not provide for a way to create a data model with type annotations from
input (e.g. it does not define anything like the PSVI).  This is
required for a type-aware query system.  It may be possible to define a
type system for RELAX NG, but it would require extensive work and
invention, and would be an inappropriate activity the XQuery WG.  It
would also
delay it significantly.

The final question is whether or not XQuery would be better served with
a much simpler type system generally.  This is really a philosophical
discussion all to its own, but, suffice it to say here that the working
group has always felt that a strong, robust and powerful type system was
fundamental to achieving the goals we set out to achieve, both in terms
of enabling performance optimization and providing features to the user.
The main question for us was whether to align this with XML Schema or
not, and we have done so for the reasons alluded above.

Finally we cannot, realistically, adopt a "configurable" type system
that would support a variety of different type systems.  This requires a
great
deal of research in a difficult area.  Again, we do not think this is an
appropriate activity for the XML Query WG and undertaking it would lead
to significant delay.

In his mail Tim says: "In particular, ISO has a serious effort underway
to create standards which describe multiple XML schema languages".  It
is probably useful for the XML Query WG to be cognizant of this work and
take advantage of it if need be.

[1]
http://lists.w3.org/Archives/Public/public-qt-comments/2002Jul/0007.html


All the best, Ashok 
===========================================================
Ashok Malhotra              <mailto: ashokma@microsoft.com> 
Microsoft Corporation
212 Hessian Hills Road
Croton-On-Hudson, NY 10520 USA 
Redmond: 425-703-9462                New York: 914-271-6477 
Received on Thursday, 19 September 2002 04:22:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:23 GMT