[ nodeset equivalence in intersection extension functions/elements ]

Hi,

Context: equivalence of nodesets containing "ELEMENT" nodes.

Mike Kay's book states: "2 node-sets are equal (returns true in an
expression) if there is a pair of nodes, one from each node-set, that have
the same string value"

This definition to me is confusing since sometimes we want only the nodes
with same "nodeName", attribute lists and string-value to be considered
equal. In other words, I want strict equivalence. Sample below illustrates -

Sample xml #1:

<foo>
<a onClick="fire();">Arthur<x>Dent</x></a>
<b style="color:blue;">Arthur<y>Dent</y></b>
</foo>

Thus nodeset ( /foo/a ) is equivalent to nodeset ( /foo/b ) although the
element nodeNames are different. Their string values is "ArthurDent".

Contrast this to the intersection() extension element from xt. In this case,
even the hierachy of childnodes below an element must be equivalent (in
addition to equivalent nodenames, attribute values etc...)

Sample xml #2:

<boo>
<a>
<l p="f">xxxxxx</l>
<l p="f">yyyyyy</l>
</a>
<b>
<l p="g">xxxxxx</l>
<l p="g">yyyyyy</l>
<l p="f">yyyyyy</l>
</b>
</boo>

Nodesets returned by xt:intersection(/boo/a/l, /boo/b/l) = empty

Nodesets returned by xt:intersection(/boo/a//l[@p='f'] , /boo/a/l) = all "l"
element
nodes which are immediate children of "a" - which is expected.


So my questions are:
a) Does other processors behave like xt ? Let me know the behaviour
of your favorite processors.
b) What is the right way to implement intersection() ? (if there is one)

Thanks.

Regards,

Gavin Bong
------------------------------------------------------------------------
I accept Mastercard, Visa or fully vested stock options
in pre-IPO companies with significant venture backing.


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