OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XQuery -- Reinventing the Wheel?

> 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

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.


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