[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Calculating cumulative values - Abel's solution

Subject: Re: Calculating cumulative values - Abel's solution
From: Abel Braaksma <abel.online@xxxxxxxxx>
Date: Fri, 31 Aug 2007 23:29:42 +0200
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

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.