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

RE: XQuery -- Reinventing the Wheel?

• From: Evan Lenz <elenz@x...>
• To: Michael Rys <mrys@m...>, 'Bob Kline' <bkline@r...>
• Date: Wed, 21 Feb 2001 20:17:49 -0800

Michael Rys wrote:
> Evan, you actually left out an important result of your
> simplistic formula,
> by elminiating the template rules and stratifying some of the semantics,
> XQuery aims to become better optimizable for people that care about
> performance and scalability. It also will become strongly typed if complex
> and simple type is available, which XSLT 2.0 will not be.

I fully recognize this is the reason why rules and the ancestor axis, etc.
are not a part of the XQuery language. This, however, does not address my
point.

If it's basically true that

XQuery = XSLT - templateRules - nonAbbreviatedXPathAxes %datatypes

as you seem to acknowledge, then it should be defined that way!

If a subset of XPath or XSLT is necessary in order for query implementations
to work, that's fine; define the subset.

The Quilt/XQuery authors clearly put a great deal of work into defining the
query constructs, words, syntax, etc. of XQuery. With all due respect, that
work has already been done in a rather large subset of XSLT, again modulo
datatypes.

Again, my point is that the transformation language and the query language,
if they are not the same thing, should build from a common semantic and
syntactic base.

Section 2.11 of the XSLT 2.0 Requirements WD states that XSLT 2.0 "Could
Improve Efficiency of Transformations on Large Documents," specifically
addressing the possibility of defining a subset of XPath "that does not
require random access to the source tree." This would basically be
XQL/XQuery's path language (without perhaps the requirement that expressions
be abbreviated). I just discovered this section, and I think *it* should be
the germ of the W3C XML Query Language, fully informed by the work of the
XML Query WG on the query algebra. I feel quite strongly that there is a
better way than to define an entirely new syntax and semantics, when so much
of what is needed is already found in XSLT or is slated for a future version
of XSLT.

This passage right here should be the germ of the XML Query Language syntax.
I hope that what comes out of it will make the XQuery Working Draft
obsolete, for the good of the people who would benefit from the reuse of W3C
technology where reuse is absolutely appropriate.

<quote href="http://www.w3.org/TR/2001/WD-xslt20req-20010214">
2.11 Could Improve Efficiency of Transformations on Large Documents

Many useful transformations take place on large documents consisting of
thousands of repeating "sub-documents". Today transformations over these
documents are impractical due to the need to have the entire source tree in
memory. Enabling "progressive" transformations, where the processor is able
to produce progressively more output as more input is received, is
tantamount to avoiding the need for XSLT processors to have random access to
the entire source document. This might be accomplished by:

* Identifying a core subset of XPath that does not require random access to
the source tree, or

* Consider a "transform all subtrees" mode where the stylesheet says, "Apply
the transformation implied by this stylesheet to each node that matches XXX,
considered as the root of a separate tree, and copy all the results of these
mini-transformations as separate subtrees on to the final result tree."
</quote>

Evan Lenz
XYZFind Corp.

• References:
  • RE: XQuery -- Reinventing the Wheel?
    • From: Michael Rys <mrys@m...>

• Prev by Date: RE: XQuery -- Reinventing the Wheel?
• Next by Date: RE: XQuery -- Reinventing the Wheel?
• Previous by thread: RE: XQuery -- Reinventing the Wheel?
• Next by thread: RE: XQuery -- Reinventing the Wheel?
• Index(es):
  • Date
  • Thread