[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
At 2006-05-12 10:18 +0100, Mark Williams wrote:
That's unfortunate.
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.
Indeed.
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
RE: [xsl] Incremental Numbering
Subject: RE: [xsl] Incremental Numbering From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx> Date: Fri, 12 May 2006 11:35:14 +0200 |
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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Incremental Numbering, Mark Williams | Thread | Re: [xsl] Incremental Numbering, David Carlisle |
RE: [xsl] Incremental Numbering, Mark Williams | Date | RE: [xsl] Namespace-alias using #de, Buchcik, Kasimier |
Month |
Keywords