[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Comparing direct ancestors


Subject: Re: [xsl] Comparing direct ancestors
From: Ihe Onwuka <ihe.onwuka@xxxxxxxxxxxxxx>
Date: Tue, 29 May 2012 11:02:15 +0100

On Mon, May 28, 2012 at 7:27 PM, Spencer Tickner
<spencertickner@xxxxxxxxx> wrote:
> Hi Ihe,
>
> Thanks for walking though the solution as I'm sure it will help
> others. Amazingly my mindset was exactly the same as yours, trying the
> XPath remove and replace before tearing some hair out an moving to the
> key solution proposed by David.
>
> As with any sample code I have run into a fringe scenario that has got
> me thinking of the "context" that the "use" statement,, ummm, uses.
> The fringe scenario comes up with nested allowable elements:
>
> <?xml version="1.0"?>
> <root>
>        <change-begin/>
>        <a>
>                <p>Foo<change-end/></p>
>        </a>
>        <change-begin/>
>        <b>
>                <d>
>                        <t>Bar</t>
>                </d>
>                <d>
>                        <t>Foo <p>This</p> whatever</t>
>                </d>
>        </b>
>        <change-end/>
>        <p>Nothing <change-begin/>to worry<change-end/> about</p>
> <!-- Fringe scenario -->
>        <b>
>                <d>
>                        <t><change-begin/>This <p>and</p> <t>That</t> and
<p>that and </p> a</t>
>                </d>
>        </b>
>        <change-end/>
> </root>
>
> In the last case the key puts the <change-end/> in the wrong spot
> (attributes added to show context:
>
> Output: <t preceding="0" ancestor-self="1"><change-begin/>This <p
> preceding="0" ancestor-self="2">and</p> <t preceding="1"
> ancestor-self="2">That</t> and <p preceding="2" ancestor-self="2">that
> and <change-end/></p> a</t>
>
> Desired Output: <t preceding="0" ancestor-self="1"><change-begin/>This
> <p preceding="0" ancestor-self="2">and</p> <t preceding="1"
> ancestor-self="2">That</t> and <p preceding="2" ancestor-self="2">that
> and </p> a<change-end/></t>
>

Here's another idea which might be a bit more robust.

Why not redefine the concept of an allowable element. Right now it's
p|t but it could be (refined p)|(refined t) or anything you want.
Define a key indexing the allowable elements.

Then change the cb and ce keys to anchor to one of the allowable
elements rather than p|t.


Current Thread
Keywords