Re: Accounting for Arbitrary Wrappers Without Going Ma

Based on your comment about doing "different processing" based on the input
setting it sounds like you could filter out the markup (or not) depending on
that setting. So you'd have distinct transforms downstream once you've
"forked", but it sounds like you already have that. Also, I think you should
be able to filter based on element namespace, no?

Perhaps I've misunderstood the complexity of your situation, but it seems to
me the above approach is pretty clean.

Regards,
 Bill

>>>>>>>>>>>
Date:	Mon, 21 Oct 2002 17:46:10 -0500
From:	"W. Eliot Kimber" <eliot@xxxxxxxxxx <mailto:eliot@xxxxxxxxxx> >
Subject:	 Accounting for Arbitrary Wrappers Without Going Mad

I'm trying to implement support in my FO style sheet for Epic Editor's 
change tracking markup. This markup is in a unique name space and may be 
wrapped around any element or text to indicate whether the element is 
added or deleted.

Within the scope of paragraphs it's not a big deal because the 
processing in that context is pretty simple. But above the paragraph 
level it gets pretty funky because the presence of the wrappers will 
throw off match statements. I could of course add match options that 
include the Epic change tracking elements, and would do so if that were 
the end of it. Unfortunately, I also want to do different processing 
based on the interaction of the change tracking markup and a parameter 
that's passed in (reflecting the "view change tracking" setting in Epic 
itself).

I can't think of an elegant solution to this sort of problem. An easy 
solution would be to have the XPath matches simply ignore elements in a 
particular name space, but I don't think that's possible. That would at 
least keep the base transform working whether the wrappers were there or 
not. But it wouldn't solve the larger problem of explosion of matches 
and templates.

I'm wondering if there's a general pattern for approaching this type of 
markup other than the brute force method?

Thanks,
Eliot


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list