From: David Carlisle <davidc@xxxxxxxxx>
Subject: Re: xsl:sequence
Date: Mon, 7 Aug 2006 16:41:25 +0100
> I was referring to constructing a copy of the node in the output and by
> sounds of it I'm right in still calling this a copy.
in an implementation you may be right that xsl:sequence acts like
xsl:copy-of in this context but that isn't the way the semantics are
described (and isn't the best way to think about it)
the body of an xsl instruction (xsl:template, xsl:variable, xsl:if, etc)
is always evaluated the smae way and always generates a _sequence_ so
the semantics of a particular instruction such as xsl:sequence within
that xsl instruction doesn't change depending on what the parent is.
What does change is what happens to the sequence once it is constructed.
Whether it is copied to an output, stored in a variable, merged into the
sequence being constructed by another instruction etc. In th ecase of
the main result tree, it's possible that the system never materialises
the sequence in memory and never actually makes the nodes in teh result
tree either, but simply directly serialises the result to an XMl
document. But that's an optimisation that doesn't affect the semantics
of the instructions.
> If a variable value is a reference rather than a copy what advantages
> does that provide?
it's a lot faster and a lot less memory.
If you go
<xsl:variable name="a" as="document-node()">
<xsl:variable name="b" as="document-node()">
then $b is simply a pointer to the current document, which takes no time
to build and hardly any space to store, and $b is / is true.
on the other hand $a is a document structurally identical to the
current document but it is a copy, so it takes time and memory
proportional to the size of the document to build, and $a is / is false.
> I was thinking that an attribute node contains a text node. Reading up
> an attribute node seems to *be* both the attribute name and its value.
> it is co-erced to an atomic xs:double value it somehow loses the
> name part and just takes on the value - this is what I was referring to
It may be take less space to store the sequence of attribute nodes
depends on the implementation, but logically it is just a sequence of
pointers into the existing tree, so the data doesn't need to be copied,
conversely if you store the data then you are copying the data and need
to store the sequence of doubles which may or may not be more data than
a sequence of attribute node pointers. Also of course often you _need_
to store a list of attribute nodes, for example if you need to know
whhat there parents are $variable/.. wil work on a sequence of attribute
nodes, to give a sequence of elements.
But it's wrong to think of xsl:sequence as an optimisation of
xsl;copy-of normally the important thing is that one works and the other
doesn't. (You can usually replace copy-of by sequence, but not always,
you usually can't replace xsl:sequence by copy-of)