On 3/29/2014 10:43 AM, Abel Braaksma (Exselt) wrote:
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.
I don't think I understand this. Are you saying that <xsl:template
match="@*|node()"> matches the empty sequence? That would be quite
surprising to me. I can see that <xsl:apply-templates /> on an empty
node could cause an attempt to match an empty sequence, but does that
actually fire rules?
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.
Yeah, I think that priniciple is over-stressed - as I said in an earlier
post, I think judicious suprises can be an essential spur to learning,
but I recognize this is a matter of taste.
-Mike
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--