Re: XQuery -- Reinventing the Wheel?

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

> > I certainly don't see current XSLT implementations suddenly becoming query
> > engines, performance just isn't good enough. However, a specialized XSLT
> > engine that implements a slightly modified spec and has an optimizer to
> > utilize indexes might be a much simpler way to go. Regardless it would
> > certainly be able to leverage the vast majority of the work already put
> > into XSLT vs. starting from scratch on XQuery implementations. The more
> > I think about it the more I find it a compelling idea but I just have to
> > wonder if it can be made to perform well enough.
>
> And this is where my particular expertise runs out. The XQuery people must
> think their language has the ability to perform well as a query language.

Performance IMO doesn't have so much to do with the structure of the
query language.  It has much more to do with the disposition of the data
in the
back end.

> If XSLT can't perform well in comparison to XQuery, then it would be due to
> some combination of the pattern-matching template rules and the XPath axes
> that don't have abbreviated syntaxes (BTW, this is a particularly weird way
> to specify a language, historically tied to XQL, etc.).

I don't understand this.  As any use of Google illustrates, pattern
matching is not intrinsically slow.  There are many techniques,
particularly hierarchical indexes (or search tries) for providing
efficiency in this area.  Yes, I as an XSLT implementor haven't yet
implemented such, but as I seem to have to remind people often these days,
XSLT is only about a year old.  We can hardly expect extraordinary polish
from the implementations.

How long would it take to get polished XQuery implementations?  Almost
certainly longer than it would take to have the first XSLT implementation
with logarithmic pattern-matching performance (I'd guess the most
efficient today is n log n, which is a big deal for scalability) or high
scalability of document().


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