Re: [xml-dev] XML Diff

["Fraser Goffin" <goffinf@googlemail.com>]

Thanks Philippe (and indeed everyone else who has contributed some really useful suggestions).

 

Its perhaps worth me saying that I need to analyse the documents as part of a larger [running] process, so there won't be any human intervention until the comparison is completed and the results are sent as part of a message structure to a calling ESB service user. Can XUnit operate in this mode ?

 

The results I'm looking for are the additions, deletions and content changes that have been applied to both instances.

 

Regards

 

Fraser.

 

On 02/08/07, Philippe Poulard <Philippe.Poulard@sophia.inria.fr> wrote:

Fraser Goffin a écrit :
> Has anyone come across a good Java library for comparing XML instances ?
>

hi,

you should consider XUnit :
http://reflex.gforge.inria.fr/xunit.html

XUnit does the same than JUnit, but if you have to compare 2 XML
documents, it might help ; usually you do you own stuff that produce
some datas, and as you have prepared the expected datas, you just have
to assert that the 2 datas are equals ; this is the same in XUnit, and
the 2 datas can be 2 nodes

for example :
<xunit:test-case name="myTest" label="Testing purchase order">
    <!--run your own stuff-->
    <acme:transform-purchase-order output=" result.xml" id="1234"/>

    <!--retrieve the result and the output expected-->
    <xcl:parse name="po" source="result.xml"/>
    <xcl:parse name="oe" source=" output-expected.xml"/>

    <!--check if they are equals-->
    <xunit:assert-node-equals result="{ $po }" expected="{ $oe }"
recurse="true"/>
</xunit:test-case>

the tool works on the DOM, and it will report each difference found (for
example when an attribute is missing, or when an attribute is not
expected, or when the attribute values don't match) ; at a given level,
if 2 elements don't match, the tool won't look inside their content

exemple of report :
http://reflex.gforge.inria.fr/xunit.html#checkingTheErrorReport
(if you scroll down a little, you'll find an HTML-formatted output)

it is simple, but efficient ; the output report contains the canonical
path of each node in fault (the canonical path is the XPath expression
that starts from the root and descend child from child by naming it and
setting its position regarding its parent : e.g. /root[1]/elem[5]/@attr)
namespace URIs are supplied if you have any, and they don't clash even
if some have been remapped in the documents

enjoy !

--
Cordialement,

              ///
             (. .)
--------ooO--(_)--Ooo--------
|      Philippe Poulard       |
-----------------------------
http://reflex.gforge.inria.fr/
       Have the RefleX !