in XSLT 2, tunneling a parameter works in the template call nesting order only.
Is there a recommended design pattern for "tunneling" a parameter along the
source document order? I know that this is essentially a variable as in
procedural programming, and that a solution cannot be expected directly from
The use-case at hand is that I need to maintain an item counter "variable"
along the source document flow from top to bottom. This item counter may:
- be incremented at certain nodes preceding the current (=context) node, at
any(!) level in the element hierarchy of the document
- be (non-sequentially) re-set to a different value at certain nodes (based on
their respective context)
And even more specifically: I need to re-create Word's internal list item
numbering algorithm off from on an instance of OOXML, which would allow me to
construct the actual list item marker text for any list item in the document
the same way as it would be displayed when shown in Word.
I cannot use <xsl:number> since the numbering hierarchy is not related to the
element hierarchy in the document.
Ideas so far:
1. Count relevant preceding:: nodes up to one that sets the numbering value to
some defined value. I'd have to perform this query (which may be quite "heavy",
as it needs to calculate the complex condition if a certain node satisfies a
numbering reset condition for each node considered) often, i.e. for each
preceding candidate list item for each list item in the document.
2. Perform the task in multiple steps by first annotating the source document
with pre-calculated numbering attributes in a helper-namespace on the relevant
nodes (reset condition, numbering level of the reset), then in a second step
use simpler code to produce the final numbering.
3. Not use XSLT, but re-implement the numbering algorithm in some other
language (like Java), have it run on the document tree in document-order over
the document and annotate the nodes, then proceed as in 2) with a further step.
How do you go about such problems in general? Is there a best practice?
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>