RE: XQuery - The truth comes out!

[Evan Lenz <elenz@xyzfind.com>]

Jonathan Robie wrote:
> This reformulation is helpful for me - I think I understand
> better what you
> are saying. I think that XSLT and XQuery can and should share:
>
> 1. A common data model
> 2. An algebra that defines operations on that model, and which
> defines the
> static type of the result (as far as possible).
> 3. A common path expression language - basically the stuff that
> is in XPath
> 1.0.

We may be getting somewhere here. What you've stated above goes a lot
further than what I've seen you or the Query WG say before (and I recognize
you're voicing only your own thoughts here). If XSLT down-reference pull and
XQuery minus the parent axis end up sharing a common algebra as well as data
model, then shouldn't they simply be defined as different syntaxes for the
same thing?


> I do not think that XQuery should attempt to do everything XSLT
> does and in the same way.

So far, the only real thing that I've seen that might truly benefit XQuery
over XSLT in terms of implementation and optimizability techniques would be
if XQuery supported only a down-reference path language. Note also that, if
XQuery dispenses with the parent axis, the algorithmic convertability of
XSLT template rules to XQuery queries would be lost (the parent axis is
necessary for match pattern evaluation).

Despite my affinity for template rules, I'm perfectly willing to grant that
such a move might be necessary. Also, despite my being comfortable with
XSLT's syntax (for the most part), I am starting to see the demand and hence
need for a different syntax, such as an SQL-like syntax. I believe that
another syntax could be created for XSLT down-reference pull, and the
similarity between XSLT and XQuery would become even more apparent. (Paul
Tchistopolskii's work on XSLScript might be leveraged here.)

Many people have had trouble learning XSLT, due to the difficulty of
figuring out how template rules work. By taking template rules (push) out of
the equation, XSLT would be *much* easier to learn (as well as a great deal
less powerful). I'm, of course, not proposing that template rules be removed
from XSLT. Instead, I'm suggesting that XSLT minus template rules, or
down-reference pull, i.e. an XSLT subset, be formally defined, without
regard to syntax, or with regard to two syntaxes, the XSLT syntax and the
XQuery syntax. This may slightly disrupt the current XQuery model, but not
by much at all. *That* is the primary point I've been trying to make. (BTW,
the XSLT syntax for down-reference pull is already defined in a
self-enclosed way as "Stylesheet as Literal Result Element").

XSLT 1.1 is well on its way to closing the gap between the two languages
regarding composability. The XPath 2.0 requirements are well on their way to
closing the gap between the two languages regarding datatypes. And the user
requirements among the XSLT community for a function definition mechanism
(more powerful than named templates, recursive or not) are becoming clear,
as is shown by current activity on the XSL-List. In fact, we've already seen
implementations of this, such as extensions like saxon:function.


> Even if XSLT is algorithmically convertible to XQuery and
> vice versa (which may or may not be true, we haven't worked
> through all the
> details, and that would take some time), we still might not know the
> algorithms to do this for all cases, or we might not know algorithms that
> produce a result that would execute efficiently, or we might know
> the best
> available algorithms and still find that the resulting queries are slow
> simply because XSLT is optimized for template processing and XQuery
> implementations probably will not be.

Believe it or not, I agree with all of the above, as long as you're talking
about template rules. But in the case of XSLT down-reference pull, on the
other hand, that translation should be trivial. My agreement with you here
doesn't detract from the primary point I've been trying to make.


> Look, we're trying to define a query language, we are not trying to
> replace XSLT. If we require ourselves to take on this task, we'll
> never finish our query language. This is not the problem we need to
> solve.

On the contrary, this is the problem that you needed to solve, and that you
apparently did not realize was the problem you needed to solve. Why? Because
XSLT is a query language. How is that? Among all of the XML Query
Requirements use case examples, I haven't seen one that would be
inappropriate for XSLT, especially when considering the convenient features
that will be added in future versions of XSLT.

> XQuery is not that large a language.

By that standard, neither is XSLT. The perception that XSLT is a larger
language than XQuery really is a skewed one, particularly if you take
template rules away.

Jonathan, I'm learning a great deal from this discussion, and I very much
appreciate your willingness to not only participate, but your
open-mindedness in doing so.

Evan Lenz
XYZFind Corp.

Disclaimer: Opinions expressed here are mine and mine alone, not necessarily
those of XYZFind.