[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
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,
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
[xsl] Accounting for Arbitrary Wrappers Without Going Mad
Subject: [xsl] Accounting for Arbitrary Wrappers Without Going Mad From: "W. Eliot Kimber" <eliot@xxxxxxxxxx> Date: Mon, 21 Oct 2002 17:46:10 -0500 |
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 -- W. Eliot Kimber, eliot@xxxxxxxxxx Consultant, ISOGEN International
1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] XML in IE6, Chuck White | Thread | Re: [xsl] Accounting for Arbitrary , Trevor Nash |
Re: [xsl] XLST newbie needs help, Mike Brown | Date | FW: [xsl] How to navigate the tree , Nirmala R |
Month |
Keywords