Templates in XQuery

[Martin Probst]

> Can someone try to present few use cases, that how XQuery functions
> calling xsl:apply:templates really helps?

I'd think of use cases such as transforming larger parts of
semi-structured XML. I.e., XML that has a free form structure, as
opposed to data centric XML that has a rigid, predictable structure.
Writing lots of recursive XQuery functions with typeswitches is just
annoying for that, and if you have more complex rules that don't fit
into a typeswitch, it gets worse with if/then/else chains.

Basically anything that fits the description of "do this for each of
the nodes in the tree, recursively, and pick rules by tree structure".

The other use case is people that do not want to (or cannot, because
of technical limitations) implement their own glue layer that pipes
XQuery results into XSLT efficiently. I'm not entirely sure if that's
a valid use case - most environments have a host language for that,
and XProc may or may not solve that problem more elegantly.

> I think, providing this
> functionality into XQuery (and also designing the receivers on XSLT
> side) is to accept significant complexity within the implementations.
> On XQuery side, the XQuery engine must create the context and build
> the input tree to pass on to an XSLT engine. On XSLT side, the XSLT
> engine needs to accept this as a new kind of InputSource (it may
> though wrap this new input from XQuery side, into it's existing input
> sources) and also create a XSLT specific context, and return the
> results on an XQuery side.

Depends on how you do that, and whether you already have some XSLT
processor available. If you're living on the Java platform, this might
be as simple as instantiating the template and passing a new
DOMSource(xquery result node) to it.

The devil is of course in the details, with questions about schema
type information and the various options an XSLT processor might take,
which might complicate the interface.

> This is certainly doable by implementations, given the maturity of
> XQuery and XSLT implementations we have today. But this carries
> significant burden to implementers. I think we must present sufficient
> number of use cases for the benefits in this area, before expecting
> implementations to provide these features (and also the specs defining
> them).

This "XQuery is lacking templates/integration with XSLT" seems to come
up quite a bit. That of course doesn't mean it's really needed, and it
also doesn't mean this approach is really the solution to the
(perceived) problem in the first place. So yes, we'd need more user
requirements.

Martin