[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] xsl compact syntax using xquery

Subject: [xsl] xsl compact syntax using xquery
From: Michael Sokolov <msokolov@xxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 30 Mar 2014 12:00:05 -0400

Some recent comments on this list about XSLT compact syntaxes got me thinking. Why not use XQuery as a compact syntax for XSLT? XQuery's not really great as a transformation tool since it lacks XSLT's declarative rule-matching engine.

But with functional extensions to XQuery, I think we could build that, either in XQuery itself, or as a processor extension. It shouldn't require any language changes to get something useful. XSLT templates could be represented as associations of path expressions and XQuery functions.

It might look something like this:

<xsl:template match="//foo" priority="2">...</xsl:template>
xsl:template ("//foo", function () { ... }, 2)

<xsl:stylesheet> ... templates ... </xsl:stylesheet> => let $default-mode := xsl:stylesheet ($templates, ...)

It might be simplest to make all modes explicit?

<xsl:apply-templates select="xyz" />
xsl:apply-templates (xyz, $default-mode)

In an ideal world, there could be a compact syntax that represents all of some version of XSLT.

Some differences that might be difficult to paper over:

Templates accept named parameters with default values, while functions only allow positional
parameters and all must be provided in every invocation.

I think a "translator" from XSLT to XSLT-Q (?) could supply defaulted parameter values in the apply-templates calls; this would lose some of the compactness benefit, but preserve the semantics.

Tunnel parameters don't have any analogue in XQuery. I don't see how to provide that feature in XQuery without language extensions, but maybe you have an idea, Dmitre? You always seem to be able to achieve a lot with very little.

There must be some other XSLT instructions that aren't directly available in XQuery: xsl:key, xsl:result-document, but I think these could probably provided as XQuery functions in some way, without I admit, having really thought through all the implications.

I'm idly contemplating trying to hatch a proof-of-concept of some sort. I'm counting on the wisdom of this list to deter me from wasting my time on a terrible idea. On the other hand perhaps it is a great idea and somebody else will be inspired to implement it, saving me the trouble :) What do you think?


Current Thread