RE: XQuery -- Reinventing the Wheel?

[Michael Rys <mrys@microsoft.com>]

Sorry to bring the two threads together again, but for a database person,
performance and consistent semantics often go hand-in-hand.

There has been over 20 years of research and product development in the area
of both (relational) database systems and rule-based systems. Advances have
been made in both areas. However rule-based systems have not achieved the
level of performance and scalability of query-based systems, neither in the
research area (as far as I know) nor in the commercial world. The main
reason for that is, that given a physical design, a query-based system can
compile a query into physical operator trees that can make use of statically
available information about the data and access paths. A data-driven,
rule-based system can compile some of the rules, but since the queried data
structure is "late"-bound to the query, information about the data and
access paths are often only available at execution time, which makes the
query perform inherently slower and less scalable. So the need for having
all source data available is not the big issue (it is an important issue for
a streaming transformation however where your data is not persistent).

Now I do not disagree that there is a subset of XSLT that should have the
same semantics as XQuery, but I consider defining a subset of XSLT instead
of XQuery to be a very dangerous proposition. Once you start subsetting an
existing language that way, you may lose composability (how do you make XSLT
composable without the template-rule? Chaining XSLT-files? Give me a
break...) and end up with a very messy syntax. And this assumes that you
"fix" some of the current messy semantics of XPath.

So I do not necessarily agree with your formula, because you are missing
several parameters that add the advantages of XQuery such as cleaner
semantics, better optimizability, support for very large documents,
composability of the expression language (also w.r.t.
insert/delete/updates), and - important for some people - the ability to
express a query in a few lines instead of a few pages (this is not
necessarily an exhaustive list)...

If you start adding all these things to XSLT and restrict it accordingly,
you are not going to land far away from XQuery on the semantical level. You
may get a different syntax, and that may be both a blessing and a curse
depending on your religious believe.

I do not think btw, that XQuery will replace XSLT for certain applications,
in the same way as XSLT will not be used for others. So I hope to see more
efficient XSLT implementations (and I consider ours to be very good as far
as XSLT engines go). As I said, I consider XSLT's rule-based model to be
very good for streaming transformation processing (if it is limited to an
efficient core of operations), but inferior (until proven otherwise) in the
context of large document/data management.

Best regards
Michael, again speaking solely for himself

> -----Original Message-----
> From: Evan Lenz [mailto:elenz@xyzfind.com]
> Sent: Wednesday, February 21, 2001 8:36 PM
> To: Michael Rys
> Cc: xml-dev@lists.xml.org
> Subject: RE: XQuery -- Reinventing the Wheel?
> 
> 
> Michael Rys wrote:
> > 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.
> 
> I want to address this in a separate post, because I don't 
> want my opinion
> here to muddy my larger argument, which is that the XML 
> transformation and
> XML query languages should build from a common semantic and 
> syntactic base.
> 
> Disregarding performance issues, XSLT template rules work 
> beautifully for
> XML, and I think they would work beautifully over collections of XML
> documents. While making implementors happy, it will be sad to 
> see a stunted
> specification prevent anyone from trying to implement fast 
> rule-based XML
> query engines... or even slow ones that work.
> 
> Consider the following truths:
> 
> *No query language that's remotely powerful always performs 
> well on every
> possible query.
> 
> *There are certain queries that you shouldn't execute if you 
> want speed.
> These are documentable.
> 
> *There are also certain queries that get you what you want, 
> even though you
> know it will be costly.
> 
> 
> So maybe someone has tried to implement something like XSLT's 
> template rules
> over a large data set, and they've never succeeded in 
> producing a scalable
> result. I'm still sad to see it thrown out so early. It seems 
> too early.
> 
> Evan Lenz
> XYZFind Corp.
>