[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XQuery -- Reinventing the Wheel?
- From: Jonathan Robie <Jonathan.Robie@SoftwareAG-USA.com>
- To: Evan Lenz <email@example.com>, Jonathan.Robie@SoftwareAG-USA.com,firstname.lastname@example.org
- Date: Sat, 24 Feb 2001 11:29:40 -0500
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
Issue 2 : Definitions of Operators (xquery-definition-of-operators)
Originator: XQuery Editors
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
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
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
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)
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.