[
Lists Home |
Date Index |
Thread Index
]
You can certainly implement XPath efficiently against a database; but
XPath doesn't do joins, or sorting, so for a full query language you
need something more powerful.
XSLT has capabilities that are very hard to optimize because they are
very dynamic - most notably, template rules.
Now you could try to use "XSLT without template rules" as a database
query language; at first sight, "XSLT without template rules" and XQuery
have very similar functionality, and if you eliminate one or two
complicating features they get even closer. So in that sense you are
right - there is a subset of XSLT, which an optimizer could identify,
that is just as amenable to optimization as XQuery is.
This is especially so in XSLT 2.0/XPath 2.0 where some of the semantics
(e.g. on error handling) have been relaxed to give more scope for
re-ordering of expressions. For example XPath 1.0 didn't allow you to
rearrange the order of predicates in a filter expression (or an "and"
expression) because the error behavior would change, but XPath 2.0 does
allow this, which makes it much more feasible to make use of indexes -
which is of course the key task of a query language optimizer,
everything else pales into insignificance.
So perhaps it's more a question of what implementors are doing than
anything else. XSLT is designed for transformation, so implementors are
making sure it does that job well; XQuery is designed for querying
databases, so its implementors end up making a different set of
engineering decisions.
Michael Kay
> -----Original Message-----
> From: Berend de Boer [mailto:berend@xsol.com]
> Sent: 17 February 2003 19:28
> To: michael.h.kay@ntlworld.com
> Cc: 'XML Dev'
> Subject: Re: [xml-dev] Anyone wanna speculate about what this means?
>
>
> >>>>> "MK" == Michael Kay <michael.h.kay@ntlworld.com> writes:
>
> MK> XQuery will definitely give benefits, though, when searching
> MK> large indexed databases. I think there are sound technical
> MK> reasons why XQuery is more amenable to that kind of
> MK> optimization than XSLT is: and in any case, I don't see anyone
> MK> trying to produce an XSLT implementation that can handle this
> MK> scenario.
>
> Could you expand a bit on those "sound technical reasons"? I
> just finished doing an XPath implementation on top of a
> database. As I understood it, XPath expressions form the
> basis for XQuery as well as XSLT, so the distinction should
> be in xSLT specific things, right?
>
> --
> Regards,
>
> Berend. (-:
>
>
|
