Re: XPath's role (Was: Re: [xsl] Re: . in for)

[Jeni Tennison <jeni at jenitennison dot com>]

Kevin Jones wrote:
> Without something like template support XQuery is never going to be
> as flexible as XSLT at output generation. We all know the trouble
> you get into trying to exclusively use for loop constructs to create
> XML. I can see quite a lot uses for XSLT as a post-processing stage
> to a query along with its traditional use.

I *think* that most of the problems that you encounter due to using
xsl:for-each to generate output arise when the structure of the source
document is unpredictable and you want the result to follow the
ordering of the source. This really only occurs in more
document-oriented structures, where you get mixed content and
recursive nesting.

The other distinction between xsl:for-each and xsl:template is the
fact that xsl:for-each is nested within templates whereas xsl:template
elements are top-level elements; but in XQuery you manage this nesting
problem by calling functions (and you can also handle it in XSLT in
this way - by calling templates by name).

> While I am sure its possible to make the XSLT queries more
> efficient, that is not the point. The issue is that in XSLT you
> explicitly encode the access mechanism required for your query while
> in FLWR you don't. This means the XQuery processors is going to take
> responsibility for query optimization which in XSLT is near
> impossible for a processor to do once you get beyoond using a sible
> instruction. In this case a XQuery optimizer might decide there are
> so few items we might as well search all of them and just check the
> supplier names starts with 'A' or it might take a similar approach
> to the XSLT of restricting the suppliers first knowing it has a
> quick way of finding items for a supplier. In either case we
> shouldn't know or care how it does it. For small data sets this does
> not matter at all, but as data sets gets larger its much better to
> use a query optermised FLWR than XSLT instructions.

Thank you very much for that example, which demonstrates the power of
the FLWR expression (and XQuery) very neatly.

For interest, I'd have probably done it in XSLT using keys; it would
have made the change involved in handling supplier names starting with
'A' a bit easier (change the match attribute for the relevant key).
But it still wouldn't have been optimisable in the same way as the
XQuery, I imagine.

> I think this leaves me in a position where I think XQuery is going
> to be more efficient and user friendly for certain types of query
> but lacking the expressive output control of XSLT templates. Hence
> the view that XSLT+XQuery might be a better combination than
> XSLT+(an upgraded)XPath. Ignoring the 'XQuery is not XML' issue and
> the overlap in element construction capabilities. Of course, a FLWR
> like statement could always be added to XSLT but why bother if that
> can be pinched from XQuery. I guess a database implementation of
> XQuery will be rather different than a XSLT based impmentation
> because of the different data source characteristics but that's just
> what a particular implementation is optimized for.

It depends on what you mean by XSLT+XQuery. I like the idea of using
XQuery to construct a simple XML document from a database, and having
that simple XML document passed on to an XSLT stylesheet to create the
desired result. A bit like the way XSQL (from Oracle) works.

But using XQuery as the query language in XSLT instead of XPath is a
bad idea, I think. I imagine that XQuery's optimisability and
efficiency is much helped by the fact that it doesn't have to worry
about axes other than self, parent, child, descendant,
descendant-or-self, and attribute. But if you removed these axes from
the set that XSLT can handle, it will become useless for many
document-oriented transformations.

I think that at the ends of the transformation spectrum the choice
between XQuery and XSLT should be clear: XQuery for large data-sets
and efficient joins; XSLT for document-oriented transformations. The
middle ground (transformations involved small data-oriented XML
documents) will be won by the technology that is easiest to learn and
use, and the one with the best implementation support.

I'm concerned that blurring the line between the roles of XSLT and
XPath will make XSLT 2.0 harder to learn and use and harder to
implement, while XQuery at least has consistency. In the end, I fear
that this will sideline XSLT into document-oriented transformations
that, while important, aren't the bulk market in this area. For those
who have a vested interest in XSLT, this should be worrying.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list