RE: [xsl] Incremental Numbering

Subject: RE: [xsl] Incremental Numbering
From: "Mark Williams" <mark@xxxxxxxxxxxxxxxxx>
Date: Fri, 12 May 2006 10:42:06 +0100
Thanks Ken. As suspected, but the explanation is helpful.

Back to the graft or even better a new way of looking at it!


Mark Williams

________________________________

GWSmartmove

24 St Andrews Crescent, Cardiff, CF10 3DD

E: enquiries@xxxxxxxxxxxxxxxxx
T: 02920375901
F: 02920375909

www.gwsmartmove.co.uk

The contents of this email and any attachments are the property of
Gimblett Williams Solicitors Limited and are intended for the
confidential use of the named recipient(s) only. If they have been
received by you in error please maintain confidentiality, notify us,
destroy copies and delete them from your computer. It is the
responsibility of the recipient to scan this email for viruses.


-----Original Message-----
From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxxxxxxxx]
Sent: 12 May 2006 10:35
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] Incremental Numbering

At 2006-05-12 10:18 +0100, Mark Williams wrote:
>Thanks for the response. I tried to implement this in the way
>previously mentioned. For various reasons that I won't bore you with,
>this is proving impractical.

That's unfortunate.

>However, each item that I need to number is contained in a
fo:table-row.
>Is there any way of outputting the current number of a fo:table-row
>within the table. Sort of an auto-row numbering function?

No, there are no such table semantics available.  In your situation the
stylesheet is obliged to replicate the decision-making process by which
table rows are generated, thus indicating in a side-effect-free fashion
the determination of the target row number, without having to actually
generate the target rows.

Remember that XSLT is designed to run in parallel.  If there were 10
candidate rows and only 4 actual rows, a parallelized XSLT
implementation could despatch all 10 calculations to 10 different
processors and aggregate the results in the result tree ... thus any
given calculation would not access from elsewhere it's impact in the
result tree, thus it must recalculate what it's impact in the result
tree is going to be, thus replicating the determination of the target
row number.

>I suspect this is wishful thinking on my part and that there is no
>choice here,

Indeed.

>but some pretty hard graft!

Again, that's unfortunate, but I'm worried if it appears difficult that
you may not have the required perspective on it as I'm not confident it
is a hard problem to solve from your earlier description.

Good luck ... I hope this helps understand the situation.

. . . . . . . . Ken

--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Current Thread