Re: 2 Questions: (1) about looping for declaring table

Gagan Bhalla wrote:

> Q1>>
> I am trying to create an fo:table using XSLT on an XML file which has table
> elements passed in like so:
> 
> <table width="100.00%" border="1" cols="5" rows="4">
> 
> Based on the value of the attribute cols passed in, I want to declare
> <fo:table-column> before constructing the rest of the <fo:table-body>. In
> the code fragment below, how do I get the call to the template "tableColumn"
> looped based on the value of  the attributes cols passed in rather than
> hardcoding it?

Hi Cagan,

You can organise a loop in XSLT using either:

  1. Simple recursion, where a template processes one member of a list and then
calls itself recursively to process the rest -- see for example:
http://www.vbxml.com/snippetcentral/main.asp?view=viewsnippet&lang=&id=v20010126065631

  2. The method of Wendell Piez, where you use the nodes of an existing node-set
with sufficient number of nodes and use an xsl:for-each on nodes having position()
that does not exceed the intended number of repetitions. See for example:

http://www.vbxml.com/snippetcentral/main.asp?view=viewsnippet&id=v20010324001431

  3. A recursion implementing the "Divide and Conquer" principle, where a template
calls itself twice -- first to process the first half of a list, then to process the
second half, and then combines the results. See for example:

http://groups.yahoo.com/group/XSLTalk/message/4285


>From the above three, the first works efficiently only on relatively short lists,
getting an exponential-time behaviour very soon when the length of the input list
increases. It also crashes existing XSLT processors (with the exception when
"tail-recursion" and XSLT processors optimised for tail-recursion are used). The
maximum call-stack depth is N - 1.

Existing books on XSLT only mention this first, toy-solution (or am I wrong?).

The second method requires to have in advance a node-set of the maximum possible
list-length to be processed -- that is limited to knowing in advance a pre-set limit
of the maximum length, and having to allocate in advance a big memory resource,
which may be fully used and necessary only in a few cases.

The third method can be used successfully applied when processing even very long
lists. It is proven to be of linear complexity and requires a maximum call-stack
depth of only Log2(N). 

For example, let's say you want to reverse a 1MB long string. 

The simple recursive algorithm will require a call-stack depth of 999999. It will
certainly crash due to stack overflow, or lack of memory. Even if there's enormous
memory available, it will take forever to complete.

The Piez algorithm will require that you have pre-loaded a node-set with one million
nodes -- this itself may eat the whole memory of many systems.

The "Divide and Conquer" recursive algorithm does not require any node-set to be
pre-loaded. It will use a maximum call stack depth of only 19. The time it will tke
will be very close to 1000 * the time it takes to revers a 1KB string.

Another great property of the "Divide and Conquer" recursive algorithms is that they
are inherently parallelistic and "made by design" for multiprocessor playforms. In
case an XSLT processor can "parallelise" the transformation and assign different
parts of it to different CPUs (could somebody tell if such a beast exists? Is it
necessary to have a special new xslt instruction for specifying parallel execution?)
then the whole processing of a very long list could be performed "in a flash".


Cheers,
Dimitre Novatchev.


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list