Bjorndahl, Brad wrote:
Hi,
I'm transforming DITA too. Yes, it's quite wide open in some repects.
To keep track of how deeply nested I am, I initialize tunnel
variables (such as OLdepth and Uldepth) at the topic element, and
increment them when I hit elements such as ol ($OLdepth + 1) or ul
($ULdepth + 1). When you are in the li element, include the param
statements, remembering to always specify tunnel="yes". Check the
parent to see which value you want. I think this is what tunnel
variables are for.
I considered this approach and it will certainly work but it felt a
little too statefull to me, although I am using this approach for more
general context communication down the apply-templates tree walk.
In the case of what I'm doing (DITA to InDesign preprocessing) I need to
know whether I'm in one of three or four different InDesign-significant
contexts (paragraph, lines, table, etc.) and tunnel parameters seem like
the easiest way to communicate that since a given element knows what
context it establishes and can then communicate that to its descendants.
That makes it easy to adjust the context any given element in context
establishes, much easier than if you had a function that determined the
context by applying context-specific rules.
But for list level determination it seemed more appropriate to
interrogate the local ancestry.
Does anyone have an XSLT engineering principle that would prefer one
approach over the other?
If I had to come up with one it would be that I would use queries to
inspect invariant properties of the data (e.g., how many uninterrupted
ancestor OLs I have) and tunnel parameters to communicate variable
properties, especially properties that might be changed based on context
or other conditions--I think it's generally clearer to use match= to
establish primary context rather than trying to do it through functions
that have to make context-specific decisions.
That is, whether a given element in context establishes an InDesign
paragraph context might be a question of taste or presentation style,
but the number of ancestor OLs is an invariant property of the input data.
Cheers,
Eliot
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com