Re: XQuery -- Reinventing the Wheel?

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> XPath 1.0 does not, XPath 2.0 or XSLT 2.0 may (or whatever the wording in
> their requirement document is). The document() function is really not a
> replacement since it does not scale well to 10'000s of XML
> fragments/documents.

document() is no more than a URI resolver.  There is nothing that says it
must bring 10,000 documents into memory.  This just the way it happens to
be implemented in a lot of first-generation processors.

I have stated that I think some efficient query primitives might need to
be added to XSLT, probably in the form of extension elements, but I hardly
think that qualms about document() are excuse to reinvent the entire
framework.

I should point out that XSLT 2.0's proposed datatyping fills another gap
for a large-scale XML query language.

> 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.

Strongly typed can be dangerous when we're dealing with semi-structured
data.  Is XQuery's goal dealing with endless regiments of entirely
predictable data, large volumes of POP-style data, or both?  I have my
doubts that a single mechanism is a universal solvent for both.

So as XSLT matures, specialized techniques can and will branch out for
optimizing particular usage patterns.

> Don't get me wrong: For data-driven transformations XSLT's rule driven
> approach is great. The only problem is that have not yet seen a high
> performance/highly scalable engine for rule-based engines (and projects such
> as the ICSI project on a highly-parallel rule inference engine don't count,
> they normally test the boundary of hardware (cost)) that can compare to a
> algebra-based query engine with optimizer.

Are we all forgetting how long it took the first relational databases to
achieve decent performance?  I still remember the tremendous fanfare
generated by (pre-Microsoft) FoxPro's "Rushmore" technology, the sort of
thing which is considered quotidian these days.

I still need to hear these pressing arguments that XSLT is *fundamentally*
incapable for large-scale query.  The state of first-generation
implemenations is no argument.  There will also be a first generation of
XQuery engines.

> So for acceptance of a query language in the data community, a query
> language a la XQuery will find larger acceptance and more efficient
> implementations.

Evidence?

Don't get me wrong either.  I'm not categorically saying XQuery is otiose.
I'm just looking for the compelling impetus not to build it within the
XSLT framework.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python