[Xmlunit-general] Complex ElementQualifiers Work by Accident Only

[Stefan B. <bo...@ap...>]

Hi,

XMLUnit's trunk is almost complete from a functional point of view to
start thinking about XMLUnit 2.0 (with .NET and Java getting released in
parallel), but that's news for a different thread.

While trying to reimplement the Java 1.3 API on top of XMLUnit 2.x's
code I learned that the reason why ElementQualifier works is that
XMLUnit 1.3 sometimes ignores its results - which is counterintuitive.

The best example is RecursiveElementAndTextQualifier.  It is supposed to
help with something like this

control:
<a>
  <b>
    <c>foo</c>
  </b>
  <b>
    <c>bar</c>
  </b>
</a>

test:
<a>
  <b>
    <c>bar</c>
  </b>
  <b>
    <c>foo</c>
  </b>
</a>

where the user expects the documents to be similar and the only
difference would be that the two b's are swapped.

RecursiveElementAndTextQualifier makes two elements eligible for
comparison if the element name matches and all its decendent element
names match (and there is no more than a single element child per level)
and the nested text of the leaf element descendent match.  This works
well for the <b>s.

The problem here is, with the trunk code you won't even get there.
RecursiveElementAndTextQualifier will say the <a>s don't match.

Unless you set compareUnmatched to false in XMLUnit 1.3 it still works
because XMLUnit 1.3 will ignore the result and simply compare the two
<a>s since they are the only nodes available anyway.

This means compareUnmatched=false can make your ElementQualifier fail in
XMLUnit 1.3.

It also means I have to rethink how ElementSelectors should work in
XMLUnit 2.x since I feel compareUnmatched=true is a bad idea and don't
intend to support it in XMLUnit 2.x at all.  Any ideas?

Stefan