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

Re: [xsl] Things that make you go Hmmmm!


Subject: Re: [xsl] Things that make you go Hmmmm!
From: "Abel Braaksma (Exselt)" <abel@xxxxxxxxxx>
Date: Sat, 29 Mar 2014 15:43:40 +0100

On 29-3-2014 15:29, Michael Sokolov wrote:
> On 3/29/2014 10:05 AM, Abel Braaksma (Exselt) wrote:
>> xsl:copy-of allows deep-copying of a selected node (I would agree with
>> Liam here, if this was named xsl:deep-copy, it would have been easier to
>> memorize, but this name is here since XSLT 1.0, so there is little we
>> can do about that now). A deep-copy means an immediate copy of the
> I take this - that this is all old and decided and not going to change
> now - as your most significant point (but thanks for the full
> explanation!)

you're welcome ;)

>
> However, in hindsight, I suppose one might argue that an empty
> <xsl:copy> ought to function identically to <xsl:copy-of> (perform a
> deep copy).  Then you could do (almost) everything they both do now
> with a single instruction. That would simplify things neatly.  It
> would make it harder to create an empty node with the same name as the
> current node - but there are other ways to do that, and it's not a
> common need I think.

While a tempting idea, it wouldn't work in practice I think, even if,
for a moment, we ignore backward compatibility issues. Consider the
identity template, the deepest copy always ends up with an empty
selection in the xsl:apply-templates. This is effectively the same as an
empty sequence constructor. Your proposal would mean that:

<xsl:copy />

and

<xsl:copy>
   <xsl:apply-templates select="()" />
</xsl:copy>

would both behave differently, depending on the context node. The first
would copy the whole subtree without further processing, the second,
which also has an effectively empty sequence constructor, would only
copy the current node without its children.

We could of course write rules for these exceptions (assuming we can
travel back in time), and perhaps proposals like that have been
discussed and for this or other reasons been dismissed.

One other reason not to do so is the surprise element (or: the principle
of least surprise, if you like). Changing the semantics of an
instruction in different contexts or different versions is generally not
a good idea. One way forward (again, assuming we can travel back in
time) is to allow an attribute, deep-copy="yes|no", which, if set to
yes, would ignore the sequence constructor. But something about it still
feel awkward... So even in hindsight, I think the difference in the two
instructions have merit, except their names, which could have been
xsl:shallow-copy and xsl:deep-copy.

Cheers,

Abel Braaksma
Exselt XSLT 3.0 processor
http://exselt.net


Current Thread
Keywords