RE: XQuery -- Reinventing the Wheel?

[Jonathan Robie <Jonathan.Robie@SoftwareAG-USA.com>]

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.