xmlunit-general — Everything XMLUnit ;0)

Re: [Xmlunit-general] how to ignore an attribute

[Eric S. <pub...@da...>]

On 04/11/2013 11:47 AM, Stefan Bodewig wrote:
 > On 2013-04-11, David Rees wrote:
 >> What is the best way to go about ignoring a particular attribute?
 >
 > A custom DifferenceListener looking at the XPath is your only option,
 > I'm afraid.

Instead of filtering the Differences after the fact, one could
modify the DOM trees before pointing XMLUnit at them.

I recently took that approach; it worked out quite well.

   - Eric

Re: [Xmlunit-general] XPathContext.getXPath taking bulk of compare time

[David R. <da...@ub...>]

I've actually tracked it down to two things in the XPathContext.getXPath.

The biggest is actually the "replace(SEP + SEP, SEP)". When I remove 
that my XMLUnit benchmarks go from 0.11 to 0.06. I haven't played with 
it enough yet to know enough about why that line is there so I can 
replace it.

I also took a first crack at using dynamic programming to store the 
xpath expression in the Level objects. So its only computed once for 
each level. That took it from 0.06 to 0.04. A patch with that first 
crack is at https://sourceforge.net/p/xmlunit/bugs/61/.

d


On 4/11/13 11:59 AM, Stefan Bodewig wrote:
> On 2013-04-06, David Rees wrote:
>
>> After running some profiling on my tests I've discovered that XMLUnit
>> is taking the bulk of the time and XPathContext.getXPath is taking 58%
>> of XMLUnit's time.
> That's huge.
>
>> XPathContext.getXPath is called twice every time a comparison is done
>> to add the xpath for the control and test value to the created
>> Comparison. However, the xpath is only needed when the comparison
>> fails or if match tracking is being done. Perhaps the Comparison
>> should only be created if the compare fails or maybe the xpath should
>> only be set when compare fails?
> Are we talking 2.0 here?  Really, we've got a user :-)
>
> In that case this is not quite true.  DifferenceEvaluator is called for
> each and every comparison and the implementation might base its decision
> on the actual XPath.
>
> One option may be to somehow copy XPathContext's state into the
> Comparison and evaluate it lazily only when the XPath needs to be
> constructed.  This would require creating new objects with a copy of
> XPathContext's "path" member rather than building up the string.  In the
> end that may cause similar pressure on the garbage collector but should
> be faster than building up the string (and running replace on it).
>
> Stefan

Re: [Xmlunit-general] XPathContext.getXPath taking bulk of compare time

[David R. <da...@ub...>]

Another approach to consider, in line with your thoughts, would be to 
teach XPathContext Level's their parents. Then you could just store the 
Level in the Comparison.

Actually, since the Comparison has the nodes themselves can't it just 
compute the xpath using them (on demand)? Are there cases where this 
wouldn't work?

d

On 4/11/13 1:06 PM, David Rees wrote:
> I've actually tracked it down to two things in the XPathContext.getXPath.
>
> The biggest is actually the "replace(SEP + SEP, SEP)". When I remove 
> that my XMLUnit benchmarks go from 0.11 to 0.06. I haven't played with 
> it enough yet to know enough about why that line is there so I can 
> replace it.
>
> I also took a first crack at using dynamic programming to store the 
> xpath expression in the Level objects. So its only computed once for 
> each level. That took it from 0.06 to 0.04. A patch with that first 
> crack is at https://sourceforge.net/p/xmlunit/bugs/61/.
>
> d
>
>
> On 4/11/13 11:59 AM, Stefan Bodewig wrote:
>> On 2013-04-06, David Rees wrote:
>>
>>> After running some profiling on my tests I've discovered that XMLUnit
>>> is taking the bulk of the time and XPathContext.getXPath is taking 58%
>>> of XMLUnit's time.
>> That's huge.
>>
>>> XPathContext.getXPath is called twice every time a comparison is done
>>> to add the xpath for the control and test value to the created
>>> Comparison. However, the xpath is only needed when the comparison
>>> fails or if match tracking is being done. Perhaps the Comparison
>>> should only be created if the compare fails or maybe the xpath should
>>> only be set when compare fails?
>> Are we talking 2.0 here?  Really, we've got a user :-)
>>
>> In that case this is not quite true.  DifferenceEvaluator is called for
>> each and every comparison and the implementation might base its decision
>> on the actual XPath.
>>
>> One option may be to somehow copy XPathContext's state into the
>> Comparison and evaluate it lazily only when the XPath needs to be
>> constructed.  This would require creating new objects with a copy of
>> XPathContext's "path" member rather than building up the string.  In the
>> end that may cause similar pressure on the garbage collector but should
>> be faster than building up the string (and running replace on it).
>>
>> Stefan
>

Re: [Xmlunit-general] how to ignore an attribute

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

On 2013-04-11, David Rees wrote:

> What is the best way to go about ignoring a particular attribute? For
> example, given the following snippets how can we get XMLUnit to consider
> them equal (by ignoring the b attribute)?

> <A a="a" b="b"/>

> <A a="a" />

A custom DifferenceListener looking at the XPath is your only option,
I'm afraid.

Stefan

Re: [Xmlunit-general] XPathContext.getXPath taking bulk of compare time

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

On 2013-04-06, David Rees wrote:

> After running some profiling on my tests I've discovered that XMLUnit
> is taking the bulk of the time and XPathContext.getXPath is taking 58%
> of XMLUnit's time.

That's huge.

> XPathContext.getXPath is called twice every time a comparison is done
> to add the xpath for the control and test value to the created
> Comparison. However, the xpath is only needed when the comparison
> fails or if match tracking is being done. Perhaps the Comparison
> should only be created if the compare fails or maybe the xpath should
> only be set when compare fails?

Are we talking 2.0 here?  Really, we've got a user :-)

In that case this is not quite true.  DifferenceEvaluator is called for
each and every comparison and the implementation might base its decision
on the actual XPath.

One option may be to somehow copy XPathContext's state into the
Comparison and evaluate it lazily only when the XPath needs to be
constructed.  This would require creating new objects with a copy of
XPathContext's "path" member rather than building up the string.  In the
end that may cause similar pressure on the garbage collector but should
be faster than building up the string (and running replace on it).

Stefan

[Xmlunit-general] how to ignore an attribute

[David R. <da...@ub...>]

What is the best way to go about ignoring a particular attribute? For 
example, given the following snippets how can we get XMLUnit to consider 
them equal (by ignoring the b attribute)?

<A a="a" b="b"/>

<A a="a" />

Thanks,

dave

[Xmlunit-general] XPathContext.getXPath taking bulk of compare time

[David R. <da...@ub...>]

After running some profiling on my tests I've discovered that XMLUnit is 
taking the bulk of the time and XPathContext.getXPath is taking 58% of 
XMLUnit's time. I've attached a VirtualVM Profiler screenshot.

XPathContext.getXPath is called twice every time a comparison is done to 
add the xpath for the control and test value to the created Comparison. 
However, the xpath is only needed when the comparison fails or if match 
tracking is being done. Perhaps the Comparison should only be created if 
the compare fails or maybe the xpath should only be set when compare fails?

d

[Xmlunit-general] Upgrading the Sourceforge Project

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

Hi all,

I'm going to click "upgrade" on the Sourceforge admin page for XMLUnit
in a few minutes which will move the project to a new software platform.
Several things may change - like the Subversion URL, but the move is
promised to be smooth.

If you happen to see any stange effect, please let me know.

Stefan

[Xmlunit-general] XMLUnit for Java 1.4 Released

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

Hi all,

XMLUnit for Java 1.4's DifferenceEngine now detects the type attribute
From the XML Schema Instance namespace (xsi:type) and treats its value
like a QName, i.e. it tries to translate the value's prefix (if any) to
the associated namespace URI before comparing the values.

It also fixes a bug in assertXpathsEqual when applied to paths
containing attributes as well as a tiny bug in
FloatingPointTolerantDifferenceListener.

The release is available in source and binary form at
<https://sourceforge.net/projects/xmlunit/files/xmlunit%20for%20Java/XMLUnit%20for%20Java%201.4/>,
checksums and OpenPGP signatures should be downloaded from
<http://xmlunit.sourceforge.net/checksums/>.

Cheers

        Stefan

Re: [Xmlunit-general] using the RecursiveElementNameAndTextQualifier

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

Hi

On 2013-02-01, Suleman Butt wrote:

>            I read this problem in using the
> RecursiveElementNameAndTextQualifier on this thread:
> http://comments.gmane.org/gmane.comp.java.xmlunit.general/179

> As per Stefan Bodewig, the xmlunit version at that time was unable to
> resolve that issue.

That's not exactly what I said ;-)

Back then I said there was no built-in ElementQualifier that could do it
but that it wouldn't be too hard to write one of your own that did.
This hasn't changed at all.

Cheers

        Stefan

[Xmlunit-general] using the RecursiveElementNameAndTextQualifier

[Suleman B. <sul...@gm...>]

Hi All,
           I read this problem in using the
RecursiveElementNameAndTextQualifier on this thread:
http://comments.gmane.org/gmane.comp.java.xmlunit.general/179

I am facing exactly the same problem that is the
RecursiveElementNameAndTextQualifier is unable to compare similar elements
in different order and with attribute and text values.

As per Stefan Bodewig, the xmlunit version at that time was unable to
resolve that issue.

So my question is, If someone has managed to resolve the problem or does it
still persist?

I am using the latest xmlunit 1.3 released version.

Thanks.

--
Regards Suleman

Re: [Xmlunit-general] Test similarity with out of order nested elements

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

On 2011-10-24, Oliver Schrenk wrote:

> I guess the problem I have is with the documentation is that
> http://xmlunit.sourceforge.net/api/org/custommonkey/xmlunit/Diff.html#similar()
> states that

>> Two documents are considered to be "similar" if they contain the same
>> elements and attributes regardless of order.

I see how this might set wrong expectations.

> I will have to look into implementing my own ElementQualifier

Yell if you run into any problems.

> but I think that this is a use case which should be covered by
> XMLUnit.

XMLUnit will always need help to do it, but it probably should offer
more tools out of the box.

Stefan

Re: [Xmlunit-general] Test similarity with out of order nested elements

[Oliver S. <oli...@gm...>]

As an interim solution I ordered the generated tables and rows. I ran into some problems with different lexicographic orderings on Oracle and Java though, so the problem still persists.

I guess the problem I have is with the documentation is that   http://xmlunit.sourceforge.net/api/org/custommonkey/xmlunit/Diff.html#similar() states that

> Two documents are considered to be "similar" if they contain the same elements and attributes regardless of order.

My first thought was: "That's what I need" as it also met my expectations on how the tool should work out of the box. It should be able to do similarity checks  disregarding all ordering. I think Oxygen offers an option to do that (but thats no Java).



I will have to look into implementing my own ElementQualifier but I think that this is a use case which should be covered by XMLUnit.

Thanks
Oliver




Am 24.10.2011 um 15:39 schrieb Stefan Bodewig:

> On 2011-10-24, Oliver Schrenk wrote:
> 
>> I'm trying to write a XMLUnitTest that compares to XMLDocuments that basically have to layers of elements, that can be out of order.
> 
>> 	<root>
>> 		<table>
>> 			<id>1</id>
>> 			<row>
>> 				<c>a</c >
>> 				<c>b</c >
>> 			</row>
>> 		</table>
>> 		<table>
>> 			<id>2</id>
>> 			<row>
>> 				<c>b</c >
>> 				<c>a</c >
>> 			</row>
>> 		</table>
>> 	</root>
> 
> This - like most any question on XMLUnit we've had in a long while,
> seems we need better docs - boils down to ElementQualifiers.  You must
> help XMLUnit to pick the correct branches to compare.
> 
> For your use-case neither of the built-in ElementQualifiers will do.
> You'll have to write one yourself but that shouldn't be too hard.
> 
> If the two elements you are comparing are both <table>-elements, then
> look into the text content of the only id child and say they are only
> qualified to be compared it those contents match.  For any other element
> you can re-use the logic (or even an instance) of
> ElementAndTextQualifier as it will pick the correct <c> elements to
> compare.
> 
> HTH
> 
>        Stefan
> 
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general

Re: [Xmlunit-general] Test similarity with out of order nested elements

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

On 2011-10-24, Oliver Schrenk wrote:

> I'm trying to write a XMLUnitTest that compares to XMLDocuments that basically have to layers of elements, that can be out of order.

> 	<root>
> 		<table>
> 			<id>1</id>
> 			<row>
> 				<c>a</c >
> 				<c>b</c >
> 			</row>
> 		</table>
> 		<table>
> 			<id>2</id>
> 			<row>
> 				<c>b</c >
> 				<c>a</c >
> 			</row>
> 		</table>
> 	</root>

This - like most any question on XMLUnit we've had in a long while,
seems we need better docs - boils down to ElementQualifiers.  You must
help XMLUnit to pick the correct branches to compare.

For your use-case neither of the built-in ElementQualifiers will do.
You'll have to write one yourself but that shouldn't be too hard.

If the two elements you are comparing are both <table>-elements, then
look into the text content of the only id child and say they are only
qualified to be compared it those contents match.  For any other element
you can re-use the logic (or even an instance) of
ElementAndTextQualifier as it will pick the correct <c> elements to
compare.

HTH

        Stefan

[Xmlunit-general] Test similarity with out of order nested elements

[Oliver S. <oli...@gm...>]

I'm trying to write a XMLUnitTest that compares to XMLDocuments that basically have to layers of elements, that can be out of order.

	<root>
		<table>
			<id>1</id>
			<row>
				<c>a</c >
				<c>b</c >
			</row>
		</table> 
		<table>
			<id>2</id>
			<row>
				<c>b</c >
				<c>a</c >
			</row>
		</table>
	</root>

So table can be out of order (with different id) and their corresponding row columns can be out of order. I think it boils down to these test cases:

	@Test
	public void testIdenticalAndSimilar() throws Exception {
	      final String controlXML="<account><id>3A-00</id><name>acme</name></account>";
	      final String testXML="<account><name>acme</name><id>3A-00</id></account>";
	      final Diff diff=new Diff(controlXML, testXML);
	      assertTrue(diff.similar());
	}

	@Test
	public void testIdenticalAndSimilarWithNested() throws Exception {
	      final String controlXML="<table><id>1</id><map><k>a</k><k>b</k></map></table>";
	      final String testXML="<table><id>1</id><map><k>b</k><k>a</k></map></table>";
	      final Diff diff=new Diff(controlXML, testXML);
	      assertTrue(diff.similar());
	}

The second one should also pass but doesn't. Does anybody know a solution?

Best regards
Oliver Schrenk

Re: [Xmlunit-general] Not able to skip the nodes for comparision in xml unit

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

On 2011-09-16, Rajesh Ajjarapu wrote:

> I am using these two classes to ignore the nodes for comparision in xml
> unit. I am unsuccessful still to eliminate the element with City.

I'm sorry, but your code snippets are more or less unreadable.  Any
chance you can strip them down to the essentials and get rid of all
formatting?

You seem to have pasted the xmlUnitutility class twice but didn't paste
the Ignoreelement class.

> Ignoreelement ie = new Ignoreelement(ignore);

> Diff diff = new Diff(fr1, fr2);
> DetailedDiff detDiff = new DetailedDiff(diff);
> List differences = detDiff.getAllDifferences();

> for (Object object : differences) {

>    Difference difference = (Difference)object;

>    DifferenceEngine engine = new DifferenceEngine(diff);

You don't do anything with this instance

>    ie.differenceFound(difference);

what do you expect this to do?  You ignore the return code.

> // diff.overrideDifferenceListener(ie);

>     System.out.println("***********************");
>     System.*out*.println(difference);
>     System.out.println("***********************");
> }


Your DifferenceListener has not been used during comparisions so you
can't ignore anything here.  You must set the DifferenceListener before
the comparision is performed.  In you case this is before you invoke
diff.similar() or detDiff.getAllDifferences().

Stefan

Re: [Xmlunit-general] interfaces not working in Grails project or how to use XMLUnit outside XMLTestCase

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

On 2011-09-22, Pierre wrote:

> I'm using XMLUnit in a Grails project (http://grails.org/) and the
> example code (http://xmlunit.sourceforge.net/example.html) doesn't
> work.

> For instance: testCompareToSkeletonXML:
> junit.framework.AssertionFailedError: test XML matches control
> skeleton XML org.custommonkey.xmlunit.Diff
> [different] Expected text value '22 any street' but was '20 east cheap'

Is this the only test that fails?  Maybe we can find a pattern in those
tests that fail and those that pass.  Yes, I've read you follow-up that
it is IDEA's debugger and not grails 8-)

Stefan

Re: [Xmlunit-general] interfaces not working in Grails project or how to use XMLUnit outside XMLTestCase

[Pierre <pd...@ag...>]

Hi again,

So the issue seems to come from IntelliJ IDEA. If I "run" the example it 
works, if I "debug" with breakpoints it doesn't. All seems to work in 
Eclipse.

Would be interesting to know the source of this issue.

All the best,
Pierre

On 9/22/2011 11:35 AM, Pierre wrote:
> Hello all,
>
> I'm using XMLUnit in a Grails project (http://grails.org/) and the 
> example code (http://xmlunit.sourceforge.net/example.html) doesn't work.
>
> For instance: testCompareToSkeletonXML: 
> junit.framework.AssertionFailedError: test XML matches control 
> skeleton XML org.custommonkey.xmlunit.Diff
> [different] Expected text value '22 any street' but was '20 east cheap'
>
> Any help/tip on this would be much appreciated.
>
> All the best,
> Pierre
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
>
>
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general

[Xmlunit-general] interfaces not working in Grails project or how to use XMLUnit outside XMLTestCase

[Pierre <pd...@ag...>]

Hello all,

I'm using XMLUnit in a Grails project (http://grails.org/) and the 
example code (http://xmlunit.sourceforge.net/example.html) doesn't work.

For instance: testCompareToSkeletonXML: 
junit.framework.AssertionFailedError: test XML matches control skeleton 
XML org.custommonkey.xmlunit.Diff
[different] Expected text value '22 any street' but was '20 east cheap'

Any help/tip on this would be much appreciated.

All the best,
Pierre

[Xmlunit-general] Not able to skip the nodes for comparision in xml unit

[Rajesh A. <raj...@gm...>]

Hello,

I am using these two classes to ignore the nodes for comparision in xml
unit. I am unsuccessful still to eliminate the element with City.

Please find the code below

*

package* com.poc;
*

import* java.io.FileNotFoundException;

*

import* java.io.FileInputStream;
*

import* java.io.FileReader;
*

import* java.io.IOException;

*

import* *java.util.HashSet*;
*

import* java.util.List;
*

import* *java.util.Set*;

 *

import* org.custommonkey.xmlunit.DetailedDiff;
*

import* org.custommonkey.xmlunit.Diff;
*

import* org.custommonkey.xmlunit.Difference;
*

import* *org.custommonkey.xmlunit.DifferenceConstants*;
*

import* org.custommonkey.xmlunit.DifferenceEngine;
*

import* *org.custommonkey.xmlunit.DifferenceListener*;
*

import* org.custommonkey.xmlunit.XMLUnit;

*

import* *org.w3c.dom.Node*;
*

import* org.xml.sax.SAXException;

  *

public* *class* xmlUnitutility {

*public* *static* *void* main(String[] args) {

String fn1 = "Data/input.xml";

String fn2 = "Data/expected.xml";

String ignore = "City";

XMLUnit.*setNormalizeWhitespace*(Boolean.*TRUE*);

XMLUnit.*setIgnoreDiffBetweenTextAndCDATA*(Boolean.*TRUE*);

XMLUnit.*setIgnoreComments*(*true*);

XMLUnit.*setIgnoreAttributeOrder*(*true*);

Ignoreelement ie = *new* Ignoreelement(ignore);

*try* {

FileInputStream *in1* = *new* FileInputStream(fn1);

} *catch* (FileNotFoundException e1) {

// *TODO* Auto-generated catch block

e1.printStackTrace();

}

*try* {

FileInputStream *in2* = *new* FileInputStream(fn2);

} *catch* (FileNotFoundException e1) {

// *TODO* Auto-generated catch block

e1.printStackTrace();

}

FileReader fr1 = *null*;

FileReader fr2 = *null*;

*try* {

fr1 = *new* FileReader(fn1);

fr2 = *new* FileReader(fn2);

} *catch* (FileNotFoundException e) {

e.printStackTrace();

}

  *try* {

Diff diff = *new* Diff(fr1, fr2);

System.*out*.println("Similar? " + diff.similar());

System.*out*.println("Identical? " + diff.identical());

DetailedDiff detDiff = *new* DetailedDiff(diff);

 *List* differences = detDiff.getAllDifferences();

*for* (Object object : differences) {

 Difference difference = (Difference)object;

DifferenceEngine *engine* = *new* DifferenceEngine(diff);

// ie.RETURN_IGNORE_DIFFERENCE_NODES_IDENTICAL;

ie.differenceFound(difference);

// diff.overrideDifferenceListener(*ie*);

System.*out*.println("***********************");

System.*out*.println(difference);

System.*out*.println("***********************");

}

 } *catch* (SAXException e) {

e.printStackTrace();

} *catch* (IOException e) {

e.printStackTrace();

}

}

  }


Class which implemented Difference Listener

*

package* com.poc;
*

import* java.io.FileNotFoundException;

*

import* java.io.FileInputStream;
*

import* java.io.FileReader;
*

import* java.io.IOException;

*

import* *java.util.HashSet*;
*

import* java.util.List;
*

import* *java.util.Set*;

 *

import* org.custommonkey.xmlunit.DetailedDiff;
*

import* org.custommonkey.xmlunit.Diff;
*

import* org.custommonkey.xmlunit.Difference;
*

import* *org.custommonkey.xmlunit.DifferenceConstants*;
*

import* org.custommonkey.xmlunit.DifferenceEngine;
*

import* *org.custommonkey.xmlunit.DifferenceListener*;
*

import* org.custommonkey.xmlunit.XMLUnit;

*

import* *org.w3c.dom.Node*;
*

import* org.xml.sax.SAXException;

  *

public* *class* xmlUnitutility {

*public* *static* *void* main(String[] args) {

String fn1 = "Data/input.xml";

String fn2 = "Data/expected.xml";

String ignore = "City";

XMLUnit.*setNormalizeWhitespace*(Boolean.*TRUE*);

XMLUnit.*setIgnoreDiffBetweenTextAndCDATA*(Boolean.*TRUE*);

XMLUnit.*setIgnoreComments*(*true*);

XMLUnit.*setIgnoreAttributeOrder*(*true*);

Ignoreelement ie = *new* Ignoreelement(ignore);

*try* {

FileInputStream *in1* = *new* FileInputStream(fn1);

} *catch* (FileNotFoundException e1) {

// *TODO* Auto-generated catch block

e1.printStackTrace();

}

*try* {

FileInputStream *in2* = *new* FileInputStream(fn2);

} *catch* (FileNotFoundException e1) {

// *TODO* Auto-generated catch block

e1.printStackTrace();

}

FileReader fr1 = *null*;

FileReader fr2 = *null*;

*try* {

fr1 = *new* FileReader(fn1);

fr2 = *new* FileReader(fn2);

} *catch* (FileNotFoundException e) {

e.printStackTrace();

}

  *try* {

Diff diff = *new* Diff(fr1, fr2);

System.*out*.println("Similar? " + diff.similar());

System.*out*.println("Identical? " + diff.identical());

DetailedDiff detDiff = *new* DetailedDiff(diff);

 *List* differences = detDiff.getAllDifferences();

*for* (Object object : differences) {

 Difference difference = (Difference)object;

DifferenceEngine *engine* = *new* DifferenceEngine(diff);

// ie.RETURN_IGNORE_DIFFERENCE_NODES_IDENTICAL;

ie.differenceFound(difference);

// diff.overrideDifferenceListener(*ie*);

System.*out*.println("***********************");

System.*out*.println(difference);

System.*out*.println("***********************");

}

 } *catch* (SAXException e) {

e.printStackTrace();

} *catch* (IOException e) {

e.printStackTrace();

}

}

  }


Please help

Thanks
Rajesh

Re: [Xmlunit-general] combination of Attribute- and TextQualifier ?

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

On 2011-09-05, Mirko Schmidt wrote:

> Since I have a deep hierarchical structure I need recursive comparison
> as provided by ElementNameAndAttributeQualifier or
> ElementNameAndTextQualifier. However, since the differences are not
> solely expressed as text or attribute differences, these element
> qualifiers can't be used. When I use ElementNameAndAttributeQualifier,
> then only the species nodes are found to be equal. On the other hand, if
> I use ElementNameAndTextQualifier only the nodes tag0:ci are detected as
> equal.

> Is there a way to combine these two qualifiers?

Not with any of the existing ElementQualifiers.  Even if we had some
sort of composite ElementQualifier that likely wouldn't work out too
well - creating too many matches for elements with similar attributes or
text content but differences in the other part.  In the end you will
want to say "match attributes for the species elements and nested text
for the ci elements" and there is no way to do that without writing
custom code.

Fortunately it shouldn't be too difficult to write an implementation of
ElementQualifier yourself, just look at the code of either of the two
qualifiers you have identified.  You could simply create instances of
either of the two ElementQualifiers in your own implementation and then
dispatch to the "correct" instance based on the element name of the
current node in qualifyForComparison.  Something like

boolean qualifyForComparison(Element control, Element test) {
    if ("li".equals(control.getLocalName())) {
        return nameAndAttr.qualifyForComparison(control, test);
    }
    return nameAndText.qualifyForComparison(control, test);
}

It would become more difficult if you need more context information
(i.e. you'd only want to compare attributes on li elements that have an
species element somewhere up in their parent chain).

Stefan

[Xmlunit-general] combination of Attribute- and TextQualifier ?

[Mirko S. <mir...@iw...>]

Hi people,

xmlunit seems to be a great help for me. Thanks!
However, I have difficulties doing comparisons of complex xml data.
Please see the following example:

control:
----------
<listOfFunctionDefinitions>
    <functionDefinition id="func1">
        <tag0:math xmlns:tag0="http://www.w3.org/">
            <tag0:bvar>
                <tag0:ci> A </tag0:ci>
            </tag0:bvar>
            <tag0:bvar>
                <tag0:ci> B </tag0:ci>
            </tag0:bvar>
        </tag0:math>
    </functionDefinition>
</listOfFunctionDefinitions>
<listOfSpecies>
    <species id="spec1">
        <rdf:Bag>
            <rdf:li resource="res1"/>
            <rdf:li resource="res2"/>
        </rdf:Bag>
    </species>
    <species id="spec2">
        <rdf:Bag>
            <rdf:li resource="res3"/>
            <rdf:li resource="res4"/>
        </rdf:Bag>
    </species>
</listOfSpecies>

test:
------
<listOfFunctionDefinitions>
    <functionDefinition id="func1">
        <tag0:math xmlns:tag0="http://www.w3.org/">
            <tag0:bvar>
                <tag0:ci> B </tag0:ci>
            </tag0:bvar>
            <tag0:bvar>
                <tag0:ci> A </tag0:ci>
            </tag0:bvar>
        </tag0:math>
    </functionDefinition>
</listOfFunctionDefinitions>
<listOfSpecies>
    <species id="spec2">
        <rdf:Bag>
            <rdf:li resource="res3"/>
            <rdf:li resource="res4"/>
        </rdf:Bag>
    </species>
    <species id="spec1">
        <rdf:Bag>
            <rdf:li resource="res1"/>
            <rdf:li resource="res2"/>
        </rdf:Bag>
    </species>
</listOfSpecies>

In this test case, the nodes <tag0:ci> A and B (from the first half) as
well as <species id="spec1">  and "spec2" (from the second half) were
interchanged.

I consider the test case to equal the control case, but xmlunit tells me
it is different.

Since I have a deep hierarchical structure I need recursive comparison
as provided by ElementNameAndAttributeQualifier or
ElementNameAndTextQualifier. However, since the differences are not
solely expressed as text or attribute differences, these element
qualifiers can't be used. When I use ElementNameAndAttributeQualifier,
then only the species nodes are found to be equal. On the other hand, if
I use ElementNameAndTextQualifier only the nodes tag0:ci are detected as
equal.

Is there a way to combine these two qualifiers?

Thanks,

Mirko

Re: [Xmlunit-general] Problems using schema with Validator

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

On 2011-03-16, Andy Stevens wrote:

> Or, since the jaxp13.Validator in v1.3 says it can handle a variety of
> schema languages, is this error not being produced by XMLUnit anyway
> but by whatever default SchemaFactory it's using?

I think so.

> And if so, is there anything I can do about it? (e.g. a configuration
> setting I can pass through to the SchemaFactory somehow)

Honestly, I don't know.  If you find some sort of property that would
make your SchemaFactory instance happy, you can use the
Validator-constructor that accepts a SchemaFactory argument and pass in
your fully configured factory.

> Oh yes, I forgot to mention, I'm using IBM's 1.6 JDK (in case that has a
> bearing on the SchemaFactory that will be present) although I suppose I
> could potentially run under any other Windows JDK if that would solve the
> problem more easily.

I've commited a simple testcase that uses "foo" as prefix rather than
"xsd" to XMLUnit's svn tree[1] and it passes on my Windows7 machine
using Oracle's JDK 6 (.23) as well as the OpenJDK7 milestone (not quite
the latest) that I have installed.

Stefan

[1] http://xmlunit.svn.sourceforge.net/viewvc/xmlunit?view=revision&revision=491

Re: [Xmlunit-general] Problems using schema with Validator

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

On 2011-03-16, James Abley wrote:

> A brief inspection of the current svn HEAD hasn't shown that there is any
> hard-coded reference to xsd:schema in XMLUnit's source code.

Be sure to look into
<https://xmlunit.svn.sourceforge.net/svnroot/xmlunit/branches/xmlunit-1.x/>
when searching for the source code.  trunk is where I started XMLUnit
2.x development.

Anyway, there shouldn't be any hard-coded references to xsd in XMLUnit
at all.

<https://xmlunit.svn.sourceforge.net/svnroot/xmlunit/branches/xmlunit-1.x/src/java/org/custommonkey/xmlunit/jaxp13/Validator.java>
doesn't show any.

Stefan

Re: [Xmlunit-general] Problems using schema with Validator

[Andy S. <ins...@go...>]

Hi James,

On Wed, 2011-03-16 at 12:37 +0000, James Abley wrote:
> On 16 March 2011 01:42, Andy Stevens <ins...@go...>
> wrote:
>         "Failed to read schema document 'null', because 1) could not
>         find the
>         document; 2) the document could not be read; 3) the root
>         element of the
>         document is not <xsd:schema>".
>         
>         The 'null' I assume is just because I haven't set a specific
>         systemId on the
>         StreamSource.  However, the xsd file is certainly being found
>         (I've checked
>         the resource URL and that's fine) and can certainly be read
>         (I've dumped the
>         InputStream out to the console instead, and see the file's
>         contents).
>         However, the schema file is using "xs" as its prefix rather
>         than "xsd"
>         (with corresponding
>         xmlns:xs="http://www.w3.org/2001/XMLSchema") so the root
>         element is actually <xs:schema> not <xsd:schema>.  So it looks
>         like the
>         error is due to the 3rd option it gives.
...
>         How rigid is the Validator over the prefix being used, given
>         the namespace
>         URL itself is correct?  Is the specific prefix hard-coded
>         somewhere, or is
>         there something I can do to make it check the actual namespace
>         instead?  Or,
>         since the jaxp13.Validator in v1.3 says it can handle a
>         variety of schema
>         languages, is this error not being produced by XMLUnit anyway
>         but by
>         whatever default SchemaFactory it's using?  And if so, is
>         there anything I
>         can do about it? (e.g. a configuration setting I can pass
>         through to the
>         SchemaFactory somehow)  Given I didn't produce the schema
>         files, and the
>         fact there's quite a number of them involved, I'd prefer not
>         to have to go
>         through and find/replace the prefix in them all...
...
> 
> Can you provide a stack trace?
> 
> 
> A brief inspection of the current svn HEAD hasn't shown that there is
> any hard-coded reference to xsd:schema in XMLUnit's source code. 

Sure.  I'd moved on from validating just the schema to try validating a
document instead, but was still seeing the same message in a nested
exception further down the stack trace...

org.custommonkey.xmlunit.exceptions.XMLUnitRuntimeException: Schema is 
invalid
        at 
org.custommonkey.xmlunit.jaxp13.Validator.getInstanceErrors(Validator.java:176)
        at 
fixml.MessageBuilderTest.quickMessageTest(MessageBuilderTest.java:115)
...
Caused by: org.xml.sax.SAXParseException: schema_reference.4: Failed to 
read schema document 'null', because 1) could not find the document; 2) 
the document could not be read; 3) the root element of the document is
not 
<xsd:schema>.
        at 
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
Source)
        at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown 
Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
Source)
        at 
org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown 
Source)
        at 
org.apache.xerces.impl.xs.traversers.XSDHandler.getSchemaDocument(Unknown 
Source)
        at 
org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown 
Source)
        at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown 
Source)
        at
org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown 
Source)
        at
org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown 
Source)
        at 
org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown 
Source)
        at 
org.custommonkey.xmlunit.jaxp13.Validator.parseSchema(Validator.java:202)
        at 
org.custommonkey.xmlunit.jaxp13.Validator.getInstanceErrors(Validator.java:174)

Based on that, I reckon the message is originally coming from Xerces.
But is there anything (e.g. feature or property) I can pass through to
it via the Validator API that might get it to behave better?


Andy