[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: suggestion: xsl:modified-copy

Subject: Re: suggestion: xsl:modified-copy
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Wed, 01 Aug 2012 11:26:39 +0100
Re:  suggestion: xsl:modified-copy
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.