Re: difference between these 2 rules...

Hi Pedro,

> I think these 2 rules below should be equal, however they're different. 
> 
> rule 1:
> <rule context="A">
>   <assert test="B/C//D[@type='IN' and
> not(@value)]/@index=W/V/@targetIndex" > fail! </assert>
> </rule>

This expression compares two node-sets. According to your example data
this is
{1,2} = {1,3}
This comparison is true because in each set there is a member value so
that both values are equal (1 = 1). That's the way node-set comparisons
work in XPath.

> rule 2:        
> <rule context="A/B/C//D[@type='IN' and not(@value)]">
>   <assert test="./@index=../../../../W/V/@targetIndex"> fail! </assert>
> </rule>

Here you have two comparisons (two contexts)
1 = {1,3}
2 = {1,3}
Obviously the second one fails.

> The simple case is:
> 
> <A>
>    <B><C><unknown>
> 	<D type="IN" index="1" />
> 	<D type="IN" index="2" />
>    </unknown></C></B>
>    <W>
> 	<V targetIndex="1" />
> 	<V targetIndex="3" />
>    </W>
> </A>
> 
> The purpose of this these rules is detect any <V> element which
> '@targetIndex' is pointing to a non-existent <D> element by its
> '@index'. In this case, <V targetIndex="3" /> would fail!

No, your rule is looking for a D/@index without matching V/@targetIndex.
That means if you add <V targetIndex="2" /> then your assertions will
be true (despite the targetIndex="3" that is still there).

So you should have a 
<rule context="V">
  <assert test="@targetIndex = ..../D/@index">

(and "...." is your path to the D element)

However, why don't you use the ID/IDREF mechanism?

Cheers,
Oliver



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click