Subject: Re: [xsl] xsl:sequence From: "tom tom" <tomxsllist@xxxxxxxxxxx> Date: Tue, 08 Aug 2006 11:07:51 +0100 |
> I was thinking that an attribute node contains a text node. Reading up on it
> an attribute node seems to *be* both the attribute name and its value. When
> it is co-erced to an atomic xs:double value it somehow loses the attribute
> name part and just takes on the value - this is what I was referring to as
> waste.
From: David Carlisle <davidc@xxxxxxxxx> Reply-To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Subject: Re: [xsl] 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 the
> 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:copy-of select="/"/> </xsl:variable>
<xsl:variable name="b" as="document-node()"> <xsl:sequence select="/"/> </xsl:variable>
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 on it
> an attribute node seems to *be* both the attribute name and its value. When
> it is co-erced to an atomic xs:double value it somehow loses the attribute
> name part and just takes on the value - this is what I was referring to as
> waste.
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)
David
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] xsl:sequence, David Carlisle | Thread | Re: [xsl] xsl:sequence, David Carlisle |
Re: [xsl] Use of separator, David Carlisle | Date | Re: [xsl] xsl:sequence, David Carlisle |
Month |