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

Re: [xsl] xsl compact syntax using xquery

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

Ah, no! That looks like the thing I was talking about; I'll have to read about it.

Thanks - glad I asked :)


On 3/30/14 12:19 PM, Imsieke, Gerrit, le-tex wrote:
Hi Mike,

Are you aware of John Snelsonbs Transform.xq?
http://archive.xmlprague.cz/2012/files/xmlprague-2012-proceedings.pdf (p.171)


On 30.03.2014 18:00, Michael Sokolov wrote:
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

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