Christian,
As Andrew indicates, we can't give good specific advice without
something specific to work with.
On the other hand, I can report that in general your solution #2,
pipelining, does work well. First, traverse your document top-down or in
whatever order you need (for example, a sibling-to-sibling traversal is
sometimes useful), passing a (tunnel) parameter to perform the count; as
you go, copy the document and add a new attribute to every element that
needs one, capturing the value of the count at that point. Bind the
result to a variable, and apply templates to this temporary tree in a
second pass.
Using this method, your counting logic will be expressed by means of
template matches in the mode used in your first pass. These templates
will control the details of the traversal as well as where and how the
counter is incremented and/or reset, or not, as appropriate.
I hope this helps.
Cheers,
Wendell
On 4/12/2012 1:20 PM, Christian Roth wrote:
Hello,
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 XSLT core.
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?
Regards, Christian
--
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
--~------------------------------------------------------------------
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>
--~--