Re: [xsl] suggestion: xsl:modified-copy

Subject: Re: [xsl] suggestion: xsl:modified-copy
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Wed, 01 Aug 2012 11:26:39 +0100
On 01/08/2012 11:07, Andrew Welch wrote:
It's a bit late for 3.0, but perhaps for 3.1... sometimes it would be
useful to have the ability to copy and modify a section of the input
at the point its copied, rather than using an additional moded
identity template and no-op templates.

For example given something like:

<foo>
   <bar/>
   <baz/>
</foo>

and you want to copy the lot to the result except <baz/> you could do:

<xsl:modified-copy select="foo">
   <xsl:except select="baz"/>
</xsl:modified-copy>
We get quite close in XSLT 3.0

<xsl:apply-templates select="foo" mode="m">
<xsl:mode name="m" on-no-match="shallow-copy"/>
<xsl:template mode="m" match="baz"/>

I would love to be able to write this as

<xsl:apply-templates select="foo" on-no-match="shallow-copy">
  <xsl:template match="baz"/>
</xsl:apply-templates>

but there seems to be a "we tried that and it didn't work" reaction to this in the WG.

if you wanted to add another <baz/> you could do:


<xsl:modified-copy select="foo">
   <xsl:insert-after select="baz">
     <baz/>
   </xsl:insert-after>
</xsl:modified-copy>

Again, that's
<xsl:apply-templates select="foo" mode="m">
<xsl:mode name="m" on-no-match="shallow-copy"/>
<xsl:template mode="m" match="baz">
  <xsl:next-match/>
  <baz/>
</xsl:template>

I think it needs a more convincing use case.

It's true enough that it's difficult to achieve good performance for an application that wants to make a small change to a large tree; or especially if it wants to make lots of small changes to a large tree in a sequence of passes (so each pass sees the result of the previous passes). There's an optimization challenge there; it's basically a question of finding a good data structure to represent a (tree plus deltas), possibly combined with lazy tree construction. This would be much easier if we didn't have to worry about node identity. I don't think that new language constructs (beyond what we have in XSLT 3.0) would make such a transformation easier to optimize.

Michael Kay
Saxonica

Current Thread