[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

XQuery - The truth comes out!

• From: Evan Lenz <elenz@x...>
• To: xml-dev@l...
• Date: Sat, 24 Feb 2001 15:20:39 -0800 (PST)

Take the following observations, each of which either has been
demonstrated by Joe English or me on this list, or has been proclaimed as
the official position of the W3C XML Query and XSL WGs:

1. Template rules are a sophisticated form of syntax sugar and can be
expressed as an XQuery function -
http://lists.xml.org/archives/xml-dev/200102/msg00585.html

2. The non-abbreviated XPath axes are a sophisticated form of syntax sugar
and can be expressed as XQuery functions using the parent axis -
http://lists.xml.org/archives/xml-dev/200102/msg00604.html

3. XSLT 1.1 introduces composability by making arbitrarily constructed
trees first-class citizens -
http://lists.xml.org/archives/xml-dev/200102/msg00587.html

4. XPath 2.0 introduces W3C XML Schema datatyping, and will be used by
both XSLT 2.0 and XQuery - http://www.w3.org/TR/xpath20req


I'm sorry, but there is little else that's left. Even if we grant that the 
parent axis may be taken away from XQuery (so that the theoretical 
argument that XSLT is inherently harder to optimize might hold *some* 
water), these languages should be defined in terms of each other 
(subsets).

Regarding #1 and #2, the question's about what is *convenient* to specify,
not what is *possible* to specify--in other words, whether we should
give the user a rope to hang themselves with, even though they could go
get one on their own. Another way of looking at this is whether we should
force the user to get their own rope, even though they already had one
they liked using. (Maybe that's where the metaphor starts to break down.)
In any case, what's decided here should not preclude, at least, one
language being defined in terms of the other.

All of the work done by the Query WG on algebra and query optimization can
be leveraged and applied to XSLT as well as XQuery. There was worry about
whether it would be possible to retrofit XSLT for formal semantics. The
intermediate result of the WG shows that this should not be an impossible
task. In any case, why should XQuery be optimizable and not XSLT?

Ultimately, "XSLT" and "XQuery" should describe two different syntaxes for
the same thing and/or languages having a common semantic subset (not just
XPath!).

Evan Lenz
XYZFind Corp.

• Follow-Ups:
  • Re: XQuery - The truth comes out!
    • From: Jonathan Robie <Jonathan.Robie@S...>

• Prev by Date: RE: Why not reinvent the wheel?
• Next by Date: Re: Adding types to XPath
• Previous by thread: Re: Adding types to XPath
• Next by thread: Re: XQuery - The truth comes out!
• Index(es):
  • Date
  • Thread