- From: Ashok Malhotra <ashokma@microsoft.com>
- Date: Wed, 18 Sep 2002 15:40:34 -0400 (EDT)
- To: <tbray@textuality.com>, "Paul Cotton" <pcotton@microsoft.com>
- Cc: "XQuery Comments" <public-qt-comments@w3.org>
- Message-ID: <E5B814702B65CB4DA51644580E4853FB03DA7349@red-msg-12.redmond.corp.microsoft.com>
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 UTC