I would like to praise XMLUnit. I need to compare two WSDL files (that include other WSDL Files and XML Schemas), so that we can inform our customers of changed to our WSDL specifications from one version to another. I found XMLUnit and can only praise it.
To get it to do exactly what I want, I needed to write my own DifferenceEngine as an extension of the standard DifferenceEngine class. It was necessary to rewrite the compareNodeList () function, to change the logic. In the original version, ordering in the XML was not considered. I needed, however to consider ordering. I also needed special logic to decide whether or not two Elements were equal, if they had a "name" attribute and these were the same. This was necessary, otherwise the pre-matching got out of step when there was a list of elements of the same type, but with different "name" attributes. The effect was that without this logic, I got a lot more errors reported that were strictly there.
It would interest me to here from other developers who have extended XMLUnit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you have come away with writing DifferenceListener and ElementQualifier implementations instead of re-implementing parts of the DifferenceEngine?
I'd be interested in the sort of changes you had to make in order to allow users to achieve the same without replacing something that central to XMLUnit like the DifferenceEngine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not think so. I also had to make my own DifferenceListener. I used the default ElementQualifier. Perhaps that was a point that I overlooked.
My main problem was that my decision about whether to declare 2 XML nodes as equal depended not only on the name of the node itself, but also on the attribute tags. (I know that XMLUnit does this as well, but not quite as I needed.) Once I had found a difference, the question was what to do then. I wanted to report the difference but then somehow bring the comparison back into sync, so that subsequent comparisons would not report unnecessary differences.
First, I did not replace your DifferenceEngine, I just overloaded a couple of functions. (I did need to change XMLUnit, so that the functions were protected rather than private.) My main changes were:
a complete rewrite of compareNodeList(final List controlChildrenIn, final List testChildrenIn, final int numNodes, final DifferenceListener listener, final ElementQualifier elementQualifier)
an extension in compareElement(Element control, Element test, DifferenceListener listener), to ignore certain default attributes in XML-Schemata, where it is irrelevant whether the attribute is there or not.
What is the best way of getting my changes to you? I could paste them in the forum, but that seems rather a lot of code. Alternatively, I could email the changes.
Over to you
Best wishes
David Singleton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess it depends on what we want to do with the code. If it mainly serves as a tool to educate me, then putting it into an email is fine. If you want to use it as basis for an enhancement request, opening an issue and attaching it there would be more appropriate.
Cheers
Stefan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to praise XMLUnit. I need to compare two WSDL files (that include other WSDL Files and XML Schemas), so that we can inform our customers of changed to our WSDL specifications from one version to another. I found XMLUnit and can only praise it.
To get it to do exactly what I want, I needed to write my own DifferenceEngine as an extension of the standard DifferenceEngine class. It was necessary to rewrite the compareNodeList () function, to change the logic. In the original version, ordering in the XML was not considered. I needed, however to consider ordering. I also needed special logic to decide whether or not two Elements were equal, if they had a "name" attribute and these were the same. This was necessary, otherwise the pre-matching got out of step when there was a list of elements of the same type, but with different "name" attributes. The effect was that without this logic, I got a lot more errors reported that were strictly there.
It would interest me to here from other developers who have extended XMLUnit
Could you have come away with writing DifferenceListener and ElementQualifier implementations instead of re-implementing parts of the DifferenceEngine?
I'd be interested in the sort of changes you had to make in order to allow users to achieve the same without replacing something that central to XMLUnit like the DifferenceEngine.
I do not think so. I also had to make my own DifferenceListener. I used the default ElementQualifier. Perhaps that was a point that I overlooked.
My main problem was that my decision about whether to declare 2 XML nodes as equal depended not only on the name of the node itself, but also on the attribute tags. (I know that XMLUnit does this as well, but not quite as I needed.) Once I had found a difference, the question was what to do then. I wanted to report the difference but then somehow bring the comparison back into sync, so that subsequent comparisons would not report unnecessary differences.
First, I did not replace your DifferenceEngine, I just overloaded a couple of functions. (I did need to change XMLUnit, so that the functions were protected rather than private.) My main changes were:
a complete rewrite of compareNodeList(final List controlChildrenIn, final List testChildrenIn, final int numNodes, final DifferenceListener listener, final ElementQualifier elementQualifier)
an extension in compareElement(Element control, Element test, DifferenceListener listener), to ignore certain default attributes in XML-Schemata, where it is irrelevant whether the attribute is there or not.
What is the best way of getting my changes to you? I could paste them in the forum, but that seems rather a lot of code. Alternatively, I could email the changes.
Over to you
Best wishes
David Singleton
David,
I guess it depends on what we want to do with the code. If it mainly serves as a tool to educate me, then putting it into an email is fine. If you want to use it as basis for an enhancement request, opening an issue and attaching it there would be more appropriate.
Cheers
Stefan