[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XQuery -- Reinventing the Wheel?
At 11:21 PM 2/22/2001 -0800, Evan Lenz wrote: >Jonathan Robie wrote: > >I think I should start by responding to the title > >of this message. The phrase "reinventing the wheel" > >usually refers to reinventing something that already > >exists because you don't know about it. > >This connotation was intentional, due to the fact that the XQuery spec does >absolutely nothing to address the obvious and substantial overlap it has >with the semantics of XSLT. It was also intentional due to the fact that the >semantics of XPath are largely disregarded in the XQuery specification. The XML Query Working Group is addressing this by working together with XSL to define an XPath 2.0 that will be adequate for both XSLT and XQuery. The first Working Draft of XQuery contains a statement that this work is being done by the two Working Groups, and states that our path syntax. We also list several issues on the incompatibility between our path expression language and XPath 1.0. I will append these issues to this message, in case you had not seen them when you read the document. These issues point out that some of the semantics of XPath 1.0 are problematic for XQuery. We can't just change XPath by ourselves. That's why coordination is needed. So I think that the simple truth is that we recognize the obvious and substantial overlap, and we are working hard to address it. >It was also intentional due to XQuery's superfluous "extensions" to XPath (->, >empty(), RANGE, UNION), none of which add functionality that isn't already >there and that can't be specified quite simply in XPath. Well, we'll see which of these extensions survive the XPath 2.0 joint task force. Jonathan Issue 2 : Definitions of Operators (xquery-definition-of-operators) Originator: XQuery Editors Locus: xquery-algebra Description: XPath defines some operators on lists in ways that differ from most commonly used languages. For example, if $X is a list, $X+1 is defined as the result of adding 1 to the first element in $X (ignoring the other elements.) XQuery takes a more regular approach to operations on lists, as described in the section on functions. For example, if the function increment(integer) is defined to add 1 to its argument, then the function call increment($X) where $X is a list of integers will return a list in which every member has been incremented by 1. This issue needs more study, which should probably occur on the joint task force between XML Query and XSL. Operations on lists may be one area in which work is needed to evolve the XPath specification toward Version 2.0. It is very desirable that operators such as "+" occur only once in the grammar, not separately in the "XPath" and "non-XPath" parts of the language. This probably means that path expressions should be integrated into the XQuery grammar and not treated as a "terminal symbol." This is the approach that has been taken in the current CUP and JavaCC grammars. Expressions involving operators must also be carefully defined. We expect this to be handled by the task force on operators and the XPath 2.0 task force. Issue 17 : XPath Productions (xquery-xpath-productions) Originator: XQuery Editors Locus: xquery-algebra Description: XPath can't be treated as a terminal symbol in our grammar. We intend XQuery to be a superset of the abbreviated syntax of XPath. We do not use the grammar of XPath directly because it needs to be integrated into our other productions. For example, operators like the union operator, which occur in path expressions, also occur in other contexts in XQuery, and it makes little sense to define two different operators. This raises issues of coordination with XPath. Issue 24 : XPath Type Coercions (xquery-xpath-coercions) Originator: XQuery Editors Locus: xquery-algebra Description: XPath has a number of implicit type coercions, and also has implied existential quantification in some places. In XML 1.0, which had a small and loose type system, this was less problematic than it is with XML Schema, which introduces many types and relationships among types. If XQuery is to be compatible with XPath, we need to study these rules carefully, and adapt them to be rational and intuitive when used with the XML Schema type system. Also, there are interactions between quantification and type coercion in XPath, sometimes causing non-intuitive results. Issue 26 : Identity-based equality operator (xquery-equality-identity) Originator: Algebra Editors Locus: xquery-algebra Description: Do we need an identity-based equality operator? Please justify your answer with sample queries. Note that XPath gets along without it. Issue 27 : Deep equality (xquery-deep-equality) Originator: Jonathan Locus: xquery-algebra Description: In XPath, <book><title> Mark Twain </title></book> and <book><author> Mark Twain </author></book> are treated as equal in comparisons. Is this acceptable for us? Do we need another notion of deep equality? If so, what are the compatibility issues with XPath? These are my opinions right now. They may be quite different from the opinions of Software AG, the W3C XML Query Working Group, or the opinions that I will have after reading and considering your response.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|