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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Incremental Numbering, David Carlisle | Thread | [xsl] XSLT 2.0 Vs XSLT 1.0, Tech Savvy |
RE: [xsl] Namespace-alias using #de, Buchcik, Kasimier | Date | Re: [xsl] Incremental Numbering, David Carlisle |
Month |