Re: [xsl] Count Ancestors Up To But Not Including a Given Type

Subject: Re: [xsl] Count Ancestors Up To But Not Including a Given Type
From: Eliot Kimber <ekimber@xxxxxxxxxxxx>
Date: Tue, 05 Feb 2008 11:44:36 -0600
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

Current Thread