RE: Calculating cumulative values - Abel's solution

Abel,

Thank you so much for the explanation of the mechanisms behind your
solution.  Very informative and well written.  I will read more carefully
with consideration of the end points and try and get my nodes into the
output.

Simon

-----Original Message-----
From: Abel Braaksma [mailto:abel.online@xxxxxxxxx] 
Sent: August 31, 2007 2:30 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re:  Calculating cumulative values - Abel's solution

Simon Shutter wrote:
> Wendell,
>
> Thank you for the carefully worded clarification.  I did experiment 
> with
>
> <xsl:template match="@*|node()">
>   <xsl:copy>
>     <xsl:apply-templates select="@*|node()"/>
>   </xsl:copy>
> </xsl:template>
>
> And
>
> <xsl:template match="svg">
>     <xsl:copy>
>       <xsl:apply-templates select="@*|node()"/>
>     </xsl:copy>
>   </xsl:template>
>
> But the output is unaffected.  Is this because Abel's solution 
> includes a template for the root element and the identity template is
ignored?

No, it is a matter of end-points. Read on (I used my unaltered original code
for this rundown):

IIRC, in my solution, I first define an entry point, where the whole thing
starts, compare it to a void main() in c-style languages:

   <xsl:template match="/" >....

Next the control is transfered to the micro pipeline: the variable "catches"
this and it uses a specific mode so that it does not interfere with the
rest. After this is done, we have a long list giving "meta" 
information (or, better: the cumulative calculations) to the points. In
memory, it looks something like this (I've tried to let the example be
accurate):

<point x="1" y1="4" y2="4" y3="56" parent-id="d1e3">
   <calc x="1" y2="4" y3="56" />
   <calc x="2" y2="11" y3="23" />
</point>
<point x="1" y1="2" y2="6" y3="62" parent-id="d1e3">
   <calc x="1" y2="6" y3="62" />
   <calc x="2" y2="11" y3="23" />
</point>

(in terms of identity transform, you could consider this a transform that
keeps the structure but augments it with some data, however, the algorithm
for the calculation does tree-walk of some kind which has only remote
resemblance, if any, with the identity transform template you mention above)

Important to mention is that the <set> nodes are gone. This was necessary to
avoid using cross-node lookup with complex axes for the calculation (we
wanted a O(n) algorithm, remember?). By flattening it it was easy to do the
running totals and the semi totals, but we had to somehow keep a record of
the original parents: that is the parent-id you see above, made with
generate-id().

All this is, like I said, "captured" into a variable. Normally, with
micro-pipelining, you would re-apply this to process it further. It would'nt
be a problem to do so, but because we lost a lot of the base structure and
because performance is an issue, I decided to use it as lookup tree and pass
it on as parameter. Now we enter a normal transformation (if you ignore the
param), using no mode at all (actually, using the #default mode). [Bear with
me, I'll come to my point about priorities soon.... ].

All the matching templates without a mode are part of the actual normal
transformation. You apply all sets to it (this is important to remember: 
all sets) because we need our structure back. From here on, it looks like an
identity transform:

   <xsl:template match="set" >....
   <xsl:template match="point" >....

"looks like", because it is missing the template you mention above. Why? 
Because we are not going to apply all nodes that are contained in the
structure. We need the "new" nodes from the micro-pipeline, the augmented
ones (otherwise we have done all that work in vain). Consider the following
statement from my source:

   <xsl:apply-templates select="$points/point[@parent-id =
                generate-id(current())]" />

It selects all the points from the micro pipeline that were originally part
of the same parent (namely: the current <set> we are processing). 
You may ask me: why did you throw away these nodes, wasn't it simple to just
keep them? Well, I tried. Yes, it is possible, but a large cost of
complexity and performance. I wasn't happy with it. Maybe someone else can
do a better job, but I considered this to be quite effective in the end.

Now back to your identity transform. Why isn't it captured? If you look
closely again to the matching template for "set", you see that it does a
xsl:apply-templates on something different than its own node, and it does a
copy-of for the attributes. In other words, the passing-on that is needed
for the identity idiom to work is not applied. Yet in other
words: the processing of the original tree ends here: end-point.

There's another end-point, you can find it in the matching for the "point"
node. This is not the point as in your original source, because the points
from your original tree are not applied (see prev. 
paragraph). This is an end point because it only contains xsl:copy-of and no
apply-templates anymore.

In conclusion I would say that, to analyze any alien code and to find out
why something works, or does not work: look at the possible matching
templates where control is not passed on with another apply-templates (or
call-template, or a function or ...).

If you want to change this behavior, you will have to augment the code with
appropriate apply-templates (which will then be caught by your copy idiom).
Also, be careful about the variable holding the $points, you probably want
to pass it around and you may want to change it into a tunneling parameter
if there is more than one matching template between the one that defined the
parameter and the one that receives it (and when you don't want to
define+pass it on each and every time).


Hope this clarifies things a little for you and helps you in maintaining the
code I provided you.

Cheers,
-- Abel Braaksma