Re: [xsl] The output of evaluating an XSLT transform is the same regardless of the order in which output elements are evaluated. Right?

Subject: Re: [xsl] The output of evaluating an XSLT transform is the same regardless of the order in which output elements are evaluated. Right?
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Fri, 16 Apr 2010 14:14:01 -0700
On Fri, Apr 16, 2010 at 1:53 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>>
>> Given the following source XML B document and a data-driven (push
>> style) XSLT transformation:
>>
>> <a1>
>> B <a2>
>> B  B <a3>
>> B  B  B <a4/>
>> B  B </a3>
>> B </a2>
>> </a1>
>>
>> then the start of processing <a{N}> will be after the start
>> of processing of <a{N-1}>.
>
> As far as the language semantics are concerned, a4 is a subexpression of a3
> and is therefore evaluated first. Evaluation of a4 produces an element
node;
> evaluation of a3 copies this element node to create the child of the new a3
> element. Evaluation of a2 then copies the new a3, and so on. So contrary to
> your description, evaluation of a4 happens BEFORE a3.


Seems like a misunderstanding.

I meant this:

There was an <xsl:apply-templates> instruction that caused a template
to be selected and applied on <a4>. This <xsl:apply-templates>
instruction was processed as part of processing the parent of <a4>.
Therefore, the processing of <a3> (the parent of <a4>) started, then
the <xsl:apply-templates> was part of this processing and it caused
the processing of <a4>.

What is wrong with this?


--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play





>
> Now a real XSLT processor might behave quite differently. Saxon, for
> example, might compile this into a sequence of internal instructions:
>
> emit startElement(a1)
> emit startElement(a2)
> emit startElement(a3)
> emit startElement(a4)
> emit endElement(a4)
> emit endElement(a3)
> emit endElement(a2)
> emit endElement(a1)
>
> This is sufficiently far removed from the abstract syntax tree that to ask
> what order the source expressions are evaluated in is not very meaningful.
> It becomes even less meaningful once you have some real expressions to
> compute the names and content of the elements. For example, if the logic
> were:
>
> <xsl:template match="x">
> B <xsl:variable name="this" select="."/>
> B <a1 name="{concat($p, 1)}">
> B  B  <xsl:for-each select="*">
> B  B  B  <a2 name="{concat($p, $this/@id)}"/>
> B  B  </
> B </
> </
>
> then the expression concat($p, 1) will be turned into a global variable
that
> is computed once, the first time it is used, while the expression
concat($p,
> $this/@id) will be calculated once, during the first iteration of the
> xsl:for-each loop.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay

Current Thread