xmlunit-general — Everything XMLUnit ;0)

Re: [Xmlunit-general] Comparing XPath expressions in DifferenceEngine

[James A. <jam...@gm...>]

On 20 August 2010 01:31, Lanam, Jeff <jef...@hp...> wrote:

>  I’m trying to write a DifferenceEngine for XMLUnit 1.3 that will allow or
> reject differences based on a list of elements specified by the user. I have
> a simple one working which just compares the element names, but I would like
> to use XPath expressions for more precise specification. The problem I have
> is that the Difference.getTestNodeDetail().getXpathLocation() method
> returns a non-abbreviated expression, but I want the user to be able to use
> abbreviated syntax. Is there a way to compare two XPath expressions, using
> the control document as a reference, and determine if they are referencing
> the same element?  XPath is new to me, and I haven’t done much with XSLT or
> Java XML APIs.  Thanks for any help.
>
>
>
> Jeff Lanam
>
> Hewlett-Packard
>
>
Hi Jeff,

Can you supply a test which indicates what you're trying to do?

Cheers,

James

[Xmlunit-general] Comparing XPath expressions in DifferenceEngine

[Lanam, J. <jef...@hp...>]

I'm trying to write a DifferenceEngine for XMLUnit 1.3 that will allow or reject differences based on a list of elements specified by the user. I have a simple one working which just compares the element names, but I would like to use XPath expressions for more precise specification. The problem I have is that the Difference.getTestNodeDetail().getXpathLocation() method returns a non-abbreviated expression, but I want the user to be able to use abbreviated syntax. Is there a way to compare two XPath expressions, using the control document as a reference, and determine if they are referencing the same element?  XPath is new to me, and I haven't done much with XSLT or Java XML APIs.  Thanks for any help.

Jeff Lanam
Hewlett-Packard

Re: [Xmlunit-general] No .net samples provided for XML compare in XMLUnit

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

[I had to moderate in this post, please subscribe to the list]

> There is no enough documentation provided for .Net.

This is absolutely true.  On top of that, the .NET code can't do many
things the Java code base can, so you are likely not even getting close
to what you can do with the Java version right now.

I've set out to change this with XMLUnit 2.0 which I've been talking
about for years now.  Nothing tangible on the difference engine side,
but svn trunk already contains validation and XPath code bases that are
more or less identical for Java and .NET as well as skeleton ideas for
the difference engine.

This doesn't help you now, I now.

> I tried adding xmlunit reference and tried to find the DifferenceLinstener
> and Diff class which I could not find.

The best source of documentation is the code and the unit tests.

<http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/tags/XMLUnit.NET-0.4/src/csharp/>
<http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/tags/XMLUnit.NET-0.4/tests/csharp/>

Diff is XmlDiff and there is no equivalent of DifferenceListener at all,
sorry.

Stefan

[Xmlunit-general] No .net samples provided for XML compare in XMLUnit

[SUDHAKAR V <v.r...@gm...>]

What is the .Net equivalent code for the below Java code?
  *public* *void* testCompareToSkeletonXML() *throws* Exception {
        String myControlXML = "<location><street-address>22 any
street</street-address><postcode>XY00 99Z</postcode></location>";
        String myTestXML = "<location><street-address>20 east
cheap</street-address><postcode>EC3M 1EB</postcode></location>";
        DifferenceListener myDifferenceListener =
*new*IgnoreTextAndAttributeValuesDifferenceListener();
        Diff myDiff = *new* Diff(myControlXML, myTestXML);
        myDiff.overrideDifferenceListener(myDifferenceListener);
        assertTrue("test XML matches control skeleton XML " + myDiff,
myDiff.similar());
    }

There is no enough documentation provided for .Net.
I tried adding xmlunit reference and tried to find the DifferenceLinstener
and Diff class which I could not find.


--Regards,
svangeti.

Re: [Xmlunit-general] xml diff algorithm

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

On 2010-05-28, Johannes Lichtenberger wrote:

> I've got two HTML documents (serialized as XML) which have slightly
> different structures at the end because of a stylesheet template rule
> based on attributes (and attribute order isn't defined in XML documents
> I think):

Order of XML attributes is supposed to be irrelevant, still XMLUnit (1.x
for Java) has a difference type for it, but it is considered
recoverable.  I don't see any attributes on your HTML anyway.

>       <h4>CATEGORY I</h4>
>       <table>
>          <tr>
>             <td>DESC</td>
>             <td>Paperback</td>
>          </tr>
>          <tr>
>             <td>CODE</td>
>             <td>P</td>
>          </tr>
>       </table>

> vs.

>       ...
>       <h4>CATEGORY I</h4>
>       <table>
>          <tr>
>             <td>CODE</td>
>             <td>P</td>
>          </tr>
>          <tr>
>             <td>DESC</td>
>             <td>Paperback</td>
>          </tr>
>       </table>

> You can see that only the tr-elements are exchanged,

It's a bit more complex than that.  You have to look at the <tr>'s
grandchildren (the text nodes inside the <td> elements) to see which
<tr>s to match.

> but assertXMLEqual fales, even if I change the table structure to
> unordered lists, so I assume it's not doable

XMLUnit needs help from you to know which <tr>s to compare with each
other.  This is the purpose of the ElementQualifier
<http://xmlunit.sourceforge.net/userguide/html/ar01s03.html#ElementQualifier>.
In your case an ElementNameAndTextQualifier wouldn't be enough since you
need to match <tr>'s based on the text of their children.
RecursiveElementNameAndTextQualifier may work.

Stefan

[Xmlunit-general] xml diff algorithm

[Johannes L. <Joh...@un...>]

Hi,

I've got two HTML documents (serialized as XML) which have slightly
different structures at the end because of a stylesheet template rule
based on attributes (and attribute order isn't defined in XML documents
I think):

      ...
      <h4>CATEGORY I</h4>
      <table>
         <tr>
            <td>DESC</td>
            <td>Paperback</td>
         </tr>
         <tr>
            <td>CODE</td>
            <td>P</td>
         </tr>
      </table>
      <hr/>
      <h4>CATEGORY II</h4>
      <table>
         <tr>
            <td>DESC</td>
            <td>Mass-market Paperback</td>
         </tr>
         <tr>
            <td>CODE</td>
            <td>MMP</td>
         </tr>
      </table>

vs.

      ...
      <h4>CATEGORY I</h4>
      <table>
         <tr>
            <td>CODE</td>
            <td>P</td>
         </tr>
         <tr>
            <td>DESC</td>
            <td>Paperback</td>
         </tr>
      </table>
      <hr/>
      <h4>CATEGORY II</h4>
      <table>
         <tr>
            <td>CODE</td>
            <td>MMP</td>
         </tr>
         <tr>
            <td>DESC</td>
            <td>Mass-market Paperback</td>
         </tr>
      </table>

You can see that only the tr-elements are exchanged, but assertXMLEqual
fales, even if I change the table structure to unordered lists, so I
assume it's not doable (maybe only if 2 nodes are really adjacent (and
changed in order) the algorithm finds similar documents).

The strange thing is it doesn't find similarities with the following
fragment (CODE and DESC exchanged in the other document):

      <h4>CATEGORY I</h4>
      <ul>
         <li>CODE</li>
         <li>DESC</li>
      </ul>

vs.

      <h4>CATEGORY I</h4>
      <ul>
         <li>DESC</li>
         <li>CODE</li>
      </ul>

I've simply used assertXMLEqual, maybe I'll try it with Diff and
diff.similar(), but it should be the same according to the docu.

regards,
Johannes

[Xmlunit-general] "New" DifferenceEngine

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

Hi,

I'm writing this mail in part to share my thoughts and get feedback and
in part to help myself get a clearer picture of how I want the
difference engine of XMLUnit 2.0 to work.  It won't be too different
from the Java version of 1.x.

The difference engine compares (I)Source instances, there are already
plenty of implementations of this interface and even a fluid builder API
to create such instances.

Many of XMLUnit Java's options will be resolved by specialized Source
implementations.  There will be a CommentLessSource decorator which
strips the comments from an existing Source as a way to emulate
XMLUnit.setIgnoreComments for example.  This should also apply to all
whitespace manipulations.

The difference engine is supposed to traverse the document tree from the
root in a depth first search manner.  Even though the initial
implementation will be DOM based I hope it will be possible to provide
pull parser (StAX or XMLReader based) or event driven (SAX)
implementations that have the potential to compare bigger documents.

As the engine traverses the tree it will compare certain aspects of the
nodes - I guess I'll need to document properly which aspects that are
going to be and in which order the comparisons occur.  Basically these
comparisons will all be testing for exact equality.

If a comparison results in something that is not equal the registered
DifferenceEvaluator will be consulted (passing in
ComparisonResult.DIFFERENT) and will determine whether the difference is
recoverable (in the same sense as the term was used in 1.x),
non-recoverable or non-recoverable and comparison should stop at this
point.

The default implementation is more or less the same as of XMLUnit 1.x,
the main difference is that a Text node and a CDATA node of the same
textual content compare as recoverably different.

ComparisonListeners can be attached to the DifferenceEngine and will -
at this point - be notified of the comparison and its outcome.
Listeners take interest in successfull, failed or all comparisons and
will be notified based on the outcome.

If the DifferenceEvaluator instructed the DifferenceEngine to stop, the
comparison gets aborted otherwise the tree traversal continues.

The remaining interface/delegate is ElementSelector which replaces 1.x's
ElementQualifier.  I'm a bit torn whether a selector based on the
element's name should be the default (as it is in 1.x) or a pure order
based one.

The ElementSelector gets two DOM Elements of the control and test docs
and decides whether they can be compared.  This may require
materializing the DOM tree below each element for non-DOM
implementations - I hope to be able to do so in a lazy manner somehow
if/whenever I start implementing such engines.

The ElementSelector will be invoked whenever the child elements of an
Element are to be compared and there is more than one child.

In a forum thread somebody raised the idea to defer default element
selection to the DifferenceEngine itself if there is no explicit
ElementSelector, i.e. compare a combination of Elements and try a
different one if the comparison doesn't have a successfull outcome.  In
order to avoid duplicate comparisons this would require queueing up
comparisons to notify the listeners once the Elements are selected.  At
least I want to toy with the idea.

Stefan

[Xmlunit-general] Interfaces for DifferenceEngine in trunk

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

Hi all,

trunk [1] now has Java and .NET interfaces for a difference engine that
can do what the Java version of XMLUnit 1.3 does.  The plan is to add
DOM based implementations and port the XMLUnit Java 1.3 code base to use
it.

The ideas are very similar to XMLUnit 1.3 but with a few twists.

Instead of Difference there is a Comparison and an independent
ComparisonResult which represent "this is what I compared" and "this is
what I think of the outcome".

ComparisonListeners get notified of each Comparison, each passing
Comparison (replaces MatchTracker) or each failed Comparison (replaces
part of DifferenceListener).  ComparisonListener is a one-method
interface in Java and a delegate in .NET and it is possible to attach
multiple of them to the DifferenceEngine (using an event in .NET).

ElementSelector (a delegate in .NET) replaces ElementQualifier - there
can only be one per DifferenceEngine.

DifferenceEvaluator may alter the outcome of a comparision and tell the
DifferenceEngine to stop the comparision - replaces the remaining part
of DifferenceListener and ComparisonControler.  Again a delegate in .NET
and there can only be one per DifferenceEngine.

I intend to remove the ATTRIBUTE_ORDER difference type completely (there
is no guarantee the parser will return them in document order anyway)
and may choose to use a few different defaults from XMLUnit 1.x (like
calling Text and CDATA nodes with the same content similar).

Feedback more than welcome.

Stefan

[1] http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/main/java-core/net/sf/xmlunit/diff/
    http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/main/net-core/diff/
    but you better check out
    https://xmlunit.svn.sourceforge.net/svnroot/xmlunit/trunk/xmlunit
    for a full picture

[Xmlunit-general] New XPath Codebase in trunk

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

Hi all,

over the past week I've added an XPath engine to both the Java and .NET
code in trunk[1] (which once may become XMLUnit 2.0).  The API is pretty
similar[2] to that of XMLUnit Java 1.x and the Java implementation is
based on JAXP 1.3.  The .NET version uses XmlDocument for one method and
System.Xml.XPath for the other.

The java-legacy part of trunk which is supposed to implement XMLUnit
Java 1.x in terms of the new code base uses the new XPath code in its
JAXPXpathEngine and still passes its own tests.

It may be a good idea to account for compiled XPath expression in the
interface in some way, but right now my focus has shifted to the
difference engine.

Stefan

[1] http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/main/java-core/net/sf/xmlunit/xpath/
    http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/main/net-core/xpath/
    but you better check out
    https://xmlunit.svn.sourceforge.net/svnroot/xmlunit/trunk/xmlunit
    for a full picture

[2] method names are different and it returns an Iterable<Node> rather
    than a NodeList

Re: [Xmlunit-general] Using XMLUnit.

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

On 2010-04-14, Sneha Teckchandani <sne...@gm...> wrote:

> FYI - I had posted the same query to the mailing list as well. Now
> marking this email to it too.

You are not subscribed to the list so your mails end up in the
moderation queue and I simply didn't recognize it between all the SPAM
that the list receives (about one legitimate email is hidden between
several hundred SPAM messages, the list receives about ten SPAM messages
each day).

> Due to the lack of XMLUnit awareness around me, i turn to you for a
> detailed discussion.

That's what we are here for. 8-)

> I would like to records of my XMLs being compared instead of Line by
> Line comaprison (records with unique identifiers).  We used the
> ElementNameQualifier Interface, did override it but it did not bring
> about record comparison.

> <Code> ElementQualifier overriden.
>   public boolean qualifyForComparison(Element arg0, Element arg1)
>     {
>        try
>        {
>           if (arg0.getNodeName() != null
>                 && arg0.getNodeName().equals("POI")) /*Record Identifier is
> the firstChild Node of teh Elelment POI and hence item(0)*/
>           {
>              if(arg0.getChildNodes().item(0).getTextContent()

> .equals(arg1.getChildNodes().item(0).getTextContent()))
>                 return true;
>              else
>                 return false;
>           }
>        }
>        catch (Throwable t)//TODO add asserts
>        {
>           return false;
>        }
>        return true;
>     }
> <code>

OK, let me see.  You expect documents like

<container>
  <POI ...>
    <some-element-name>ID1</some-element-name>
  </POI>
  <POI ...>
    <some-element-name>ID2</some-element-name>
  </POI>
</container>

and want to compare elements with matching IDs, right?  In general I'd
expect RecursiveElementNameAndTextQualifier to work here, so I may be
missing a detail.

Your code assumes that calling getChildNodes().item(0) on a POI element
will return the Node corresponding to the element some-element-name - is
this true?  In my snippet above you'd likely first get a Text child node
containing a linebreak and four spaces.  You probably should make
XMLUnit and your ElementQualifier ignore whitespace.

Can you provide example snippets of real XML documents you are trying to
compare?

Stefan

Re: [Xmlunit-general] xmlunit and setSystemId

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

On 2010-03-25, James Sewell <Jam...@ar...> wrote:

> After a bit of playing I got it to work with JAXP 1.4!

Great

> SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
> Schema schema = factory.newSchema();
> Source ss = new StreamSource(inputstream, uri);
> Validator v = schema.newValidator();
> v.validate(ss);

this should be equivalent to XMLUnit's JAXP 1.3 validation with

Validator v = new Validator();
StreamSource is = new StreamSource(inputstream, uri);
boolean isValid = v.isInstanceValid(is);

if not, we should try to figure out why.

Stefan

Re: [Xmlunit-general] xmlunit and setSystemId

[James S. <Jam...@ar...>]

After a bit of playing I got it to work with JAXP 1.4!

SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
Schema schema = factory.newSchema();
Source ss = new StreamSource(inputstream, uri);
Validator v = schema.newValidator();
v.validate(ss);

Thanks for the help Stefan.

James.

-----Original Message-----
From: Stefan Bodewig [mailto:bo...@ap...]
Sent: Monday, 22 March 2010 11:44 PM
To: xml...@li...
Subject: Re: [Xmlunit-general] xmlunit and setSystemId

On 2010-03-22, James Sewell <Jam...@ar...> wrote:

> From looking at JAXP 1.3 I still can't see a way of defining an
> absolute URI to use when working with relative schema locations
> (unless this is what a ResourceResolver is for??)

Honestly I'm not sure whether ResourceResolver would be used for
schemaLocation hints since the docs (for
SchemaFactory#setResourceResolver) only talk about import and include.
It may be worth a try, but I'm afraid XMLUnit currently wouldn't give
you the access you'd need.

> As mentioned all my schema location information is included by way of
> xsi:SchemaLocation elements, but as they are relative (to the original
> XML document location) I need to be able to define a URI to use as a
> base.

If you are specifiying your input (the XML document) as a Source
instance it may be sufficient if this Source has the correct system ID.
I know you've tried that for the SAX InputSource used in the "old"
validation API, maybe JAXP13's take will yield better results.

> I could grab the elements from the XML document and use these schemas
> with addSchemaSource, but it seems like this should be unnecessary?

I agree there should be a better way.  Unfortunately I haven't played
with that part of JAXP too much, so I can't help much more than ask you
to try out things.

Stefan

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Xmlunit-general mailing list
Xml...@li...
https://lists.sourceforge.net/lists/listinfo/xmlunit-general

The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.

Re: [Xmlunit-general] xmlunit and setSystemId

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

On 2010-03-22, James Sewell <Jam...@ar...> wrote:

> From looking at JAXP 1.3 I still can't see a way of defining an
> absolute URI to use when working with relative schema locations
> (unless this is what a ResourceResolver is for??)

Honestly I'm not sure whether ResourceResolver would be used for
schemaLocation hints since the docs (for
SchemaFactory#setResourceResolver) only talk about import and include.
It may be worth a try, but I'm afraid XMLUnit currently wouldn't give
you the access you'd need.

> As mentioned all my schema location information is included by way of
> xsi:SchemaLocation elements, but as they are relative (to the original
> XML document location) I need to be able to define a URI to use as a
> base.

If you are specifiying your input (the XML document) as a Source
instance it may be sufficient if this Source has the correct system ID.
I know you've tried that for the SAX InputSource used in the "old"
validation API, maybe JAXP13's take will yield better results.

> I could grab the elements from the XML document and use these schemas
> with addSchemaSource, but it seems like this should be unnecessary?

I agree there should be a better way.  Unfortunately I haven't played
with that part of JAXP too much, so I can't help much more than ask you
to try out things.

Stefan

Re: [Xmlunit-general] xmlunit and setSystemId

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

Hi James,

On 2010-03-19, James Sewell <Jam...@ar...> wrote:

>             try   {
>                   v = new org.custommonkey.xmlunit.Validator(is);
>                   v.useXMLSchema(true);
>                   if (!v.isValid()) {
>                         throw new ValidationError(v.toString());
>                   }

You may consider using the JAXP 1.3 validator instead when you do schema
validation (if your Java class library supports JAXP 1.3, that is), see
<http://xmlunit.sourceforge.net/userguide/html/ar01s04.html#JAXP%201.3%20Validation>.
Using this you have more control over your schema locations.

> I realize that because I am using an InputSource I have lost any
> location information from my XML, so I have tried using

> is.setSystemId(http://www.test.org);

system ID really is something from the DTD part of XML's heritage, you
could explicitly specify this using one of the alternative constructors
of Validator.  It doesn't help, though, since the system ID is not what
the XML parser is going to use for schema locations.

If you want or must stick to the older API, the Validator's
setJAXP12SchemaSource() is what you are looking for, see
<http://xmlunit.sourceforge.net/userguide/html/ar01s04.html#XML%20Schema%20Validation>

Cheers

        Stefan

[Xmlunit-general] xmlunit and setSystemId

[James S. <Jam...@ar...>]

Greetings,

Chances are I am missing something critical here, but here goes anyway.

I am trying to validate some xml as follows:

InputSource is = new InputSource(new StringReader(response));
            Validator v;

            try   {
                  v = new org.custommonkey.xmlunit.Validator(is);
                  v.useXMLSchema(true);
                  if (!v.isValid()) {
                        throw new ValidationError(v.toString());
                  }

An example of a test XML doc (let's say this is from www.test.org/sample.xml) I have been using is as follows:


<person xmlns="http://www.cafeconleche.org/namespaces/person" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.test.org/namespaces/person
 person.xsd"><http://www.elharo.com/person.xs%22%3e>
<name>
<first_name>Alan</first_name>
<last_name>Turing</last_name>
</name>
<profession>computer scientist</profession>
<profession>mathematician</profession>
<profession>cryptographer</profession>
</person>

In this example xmlunit will try to grab person.xsd from my local machine's working directory. I want it to grab it from www.test.org/person.xsd<http://www.test.org/person.xsd> (I would like to avoid putting an absolute path in though).

I realize that because I am using an InputSource I have lost any location information from my XML, so I have tried using

is.setSystemId(http://www.test.org);

to set the relative path. This doesn't seem to have worked.

I am guessing I am misunderstanding something here, any ideas?

Cheers,
James Sewell

________________________________
The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.

Re: [Xmlunit-general] Comparison of XML that is conformant to a given XSD

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

On 2010-02-17, Nicholas W <44...@lo...> wrote:

> I can check that a piece of XML validates with an XSD that I have in a
> jar like this:

[snip]

> And I can assert that two pieces of XML are similar like this:

[snip]

> But how can I compare two XML strings that are conformant to an XSD in
> a jar?

I'm not sure I understand what you want.  You've already shown how two
compare two XML strings so what else do you need?

Are you looking for a way to assert that two pieces of XML conform to
the same schema and are similar?  There is no built-in way to do that,
you have to implement it in three steps just as you've shown.

Stefan

[Xmlunit-general] Comparison of XML that is conformant to a given XSD

[Nicholas W <44...@lo...>]

I can check that a piece of XML validates with an XSD that I have in a
jar like this:


InputSource xmlSource = resourceAsInputSource(resourcepath);
InputSource xsdInputSource = resourceAsInputSource(XsdPath);
xsdInputSource.setSystemId(xsduri);
assertNotNull(xsdInputSource);
Validator validator = new Validator(xmlSource);
validator.useXMLSchema(true);
validator.setJAXP12SchemaSource(xsdInputSource);
assertXMLValid(validator);


And I can assert that two pieces of XML are similar like this:

assertNotNull(result);
assertNotNull(resourcelocation);
log.debug(String.format("AssertStringXMLLikeResourceXML(%s)",resourcelocation));
saveResultCopy(result, resourcelocation);
InputStream resourceAsStream = this.getClass().getClassLoader()
				.getResourceAsStream(resourcelocation);
assertNotNull(resourceAsStream);
String readerToString = FileIO.readerToString(new BufferedReader(
new InputStreamReader(resourceAsStream,"utf-8")));
log.debug(String.format("expected XML - %s",readerToString));		
		assertXMLEqual(readerToString,result);



But how can I compare two XML strings that are conformant to an XSD in a jar?

I need to do this as the XSD use xs:all and minOccurs=0 in the
xs:element to indicate that some elements are optional and can appear
in any order. The XMLs I wish to compare do have the elements in a
different order, but need to be considered the same and the test
should pass.

Thanks in advance for your help,
Regards,

Re: [Xmlunit-general] Possible bug in the XMLUnit comparision logic for Nodes

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

On 2009-12-15, Dubey, Tarun <Tar...@sa...> wrote:

> The following test case fails while according to the javadocs of
> similar() method in Diff this should pass

>     @Test
>     public void testXmlIgnoreOrder() throws IOException, SAXException {
>         XMLUnit.setIgnoreWhitespace(true);
>         XMLUnit.setIgnoreAttributeOrder(true);
>         String xml1 =
>                 "<TEST><FLIGHT NUM=\"121\"></FLIGHT><FLIGHT
> NUM=\"122\"></FLIGHT></TEST>";

>         String xml2 =
>                 "<TEST><FLIGHT NUM=\"122\"></FLIGHT><FLIGHT
> NUM=\"121\"></FLIGHT></TEST>";
>         Diff diff = XMLUnit.compareXML(xml1, xml2);
>         Assert.assertTrue(diff.similar());
>     }

No, it should fail.  IgnoreAttributeOrder affects whether the order of
attributes of a single element is significant.  All your elements only
have a single attribute, so order of them is the same anyway.

What is different is the order of elements.

If the order of elements is not significant to you, you'll have to help
XMLUnit decide which elements to compare by overriding the
ElementQualifier.  The default implementations only looks at element
names, if the names are the same, it will compare the elements.

> Surprisingly the same test passes if the element names are different as
> shown below

>                 "<TEST><FLIGHT NUM=\"121\"></FLIGHT><CRUISE
> NUM=\"122\"></CRUISE></TEST>";

Yes.  If the names are different, the FLIGHT elements and the CRUISE
elements get matched against each other.  If they are the same, XMLUnit
will match them in the order they occur.

You want to use an ElementNameAndAttributeQualifier
<http://xmlunit.sourceforge.net/userguide/html/ar01s03.html#ElementNameAndAttributeQualifier>

Stefan

[Xmlunit-general] Possible bug in the XMLUnit comparision logic for Nodes

[Dubey, T. <Tar...@sa...>]

Hi,

 

The following test case fails while according to the javadocs of
similar() method in Diff this should pass

 

    @Test

    public void testXmlIgnoreOrder() throws IOException, SAXException {

        XMLUnit.setIgnoreWhitespace(true);

        XMLUnit.setIgnoreAttributeOrder(true);

        String xml1 =

                "<TEST><FLIGHT NUM=\"121\"></FLIGHT><FLIGHT
NUM=\"122\"></FLIGHT></TEST>";

        String xml2 =

                "<TEST><FLIGHT NUM=\"122\"></FLIGHT><FLIGHT
NUM=\"121\"></FLIGHT></TEST>";

        Diff diff = XMLUnit.compareXML(xml1, xml2);

        Assert.assertTrue(diff.similar());

 

    }

Surprisingly the same test passes if the element names are different as
shown below

    @Test

    public void testXmlIgnoreOrder() throws IOException, SAXException {

        XMLUnit.setIgnoreWhitespace(true);

        XMLUnit.setIgnoreAttributeOrder(true);

        String xml1 =

                "<TEST><FLIGHT NUM=\"121\"></FLIGHT><CRUISE
NUM=\"122\"></CRUISE></TEST>";

        String xml2 =

                "<TEST><CRUISE NUM=\"122\"></CRUISE><FLIGHT
NUM=\"121\"></FLIGHT></TEST>";

        Diff diff = XMLUnit.compareXML(xml1, xml2);

        Assert.assertTrue(diff.similar());

 

    }

 

Is this bug already been reported ? If yes please can you let me know
where to find the fix or a workaround ?

 

Thanks

Tarun Dubey

 

Re: [Xmlunit-general] How to validate a Word 2007 XML file with XMLUnit?

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

On 2009-11-16, max muster <beh...@go...> wrote:

> How to validate a Word 2007 XML file against a Schema?
> Is it possible to use XMLUnit to formulate a Testcase?

Yes, it is, I'm just not sure whether you want to use the Java or the
.NET version.

For Java you'll find examples in the user guide:
<http://xmlunit.sourceforge.net/userguide/html/ar01s04.html>

For .NET you'd use the Validator class.

If you feel bold you can try the (currently stuck) XMLUnit 2.0 codebase
which already does validation in a very similar way on both platforms.
See for example

<http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/tests/net-core/validation/ValidatorTest.cs?view=log>

for .NET

Stefan

[Xmlunit-general] How to validate a Word 2007 XML file with XMLUnit?

[max m. <beh...@go...>]

Hi guys,

Thank you for giving us XMLUnit we like it very much!

Now I run into a problem that I hope XMLUnit could also solve.
How to validate a Word 2007 XML file against a Schema?
Is it possible to use XMLUnit to formulate a Testcase?

/behindthevoid

Re: [Xmlunit-general] HTMLDocumentBuilder and &nbsp; bug?

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

On 2009-10-20, Tony Rozga <ton...@ni...> wrote:

> I'm using XMLUnit primarily for HTMLDocumentBuilder and
> TolerantSaxDocumentBuilder (nice tools btw!).

Honestly, I would have thought they had been obsoleted by things like
tagsoup or jtidy.

> If I build a Document from html with &nbsp; in it the String contents
> of the Node in question have weird bytes where the space should be.

There are way more space characters in Unicode than you'll ever want to
know.  In particular there is a "non-breaking space" character and I
guess this is what you see as "weird bytes".  &nbsp; is not a simple
space and so you can't expect to get that.

Stefan

[Xmlunit-general] HTMLDocumentBuilder and &nbsp; bug?

[Tony R. <ton...@ni...>]

Hi,
I'm using XMLUnit primarily for HTMLDocumentBuilder and 
TolerantSaxDocumentBuilder (nice tools btw!).   If I build a Document 
from html with   in it the String contents of the Node in question 
have weird bytes where the space should be.  I ran into this trying to 
split a resulting string on whitespace.

For example, with <body>test&nbsp;after</body>, the body text string I 
get has the following utf-8 bytes:

bytes: 116 101 115 116 -62 -96 97 102 116 101 114

I was expecting to find 32 where the -62 and -96 are.  Bug?

I'm using latest version with java 1.6.0.16.

Thanks,
Tony Rozga

Here is a test (not JUnit though :):


import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathExpression;
import javax.xml.xpath.XPathFactory;
import org.custommonkey.xmlunit.HTMLDocumentBuilder;
import org.custommonkey.xmlunit.TolerantSaxDocumentBuilder;
import org.custommonkey.xmlunit.XMLUnit;
import org.w3c.dom.Document;
import org.w3c.dom.NodeList;


public class XmlUnitBug {

    public static void main(String[] args) {

        try {
          
            String html = "test&nbsp;after";
            TolerantSaxDocumentBuilder tolerantSaxDocumentBuilder = new 
TolerantSaxDocumentBuilder(XMLUnit.newTestParser());
            HTMLDocumentBuilder builder = new 
HTMLDocumentBuilder(tolerantSaxDocumentBuilder);
            Document doc = builder.parse(html);

            XPathFactory factory = XPathFactory.newInstance();
            XPath xpath = factory.newXPath();
            XPathExpression expr = xpath.compile("/html/body");
            String body = ((NodeList) expr.evaluate(doc, 
XPathConstants.NODESET)).item(0).getTextContent();
            System.out.println("body: " + body);
            System.out.print("bytes: ");
            byte[] bytes = body.getBytes("UTF-8");
            for (byte b : bytes) {
                System.out.print(b);
                System.out.print(" ");
            }
            System.out.println("");
        } catch (Exception ex) {
            System.out.println("whoops: " + ex);
        }
    }
}

[Xmlunit-general] solved: comparing XMLs containing space characters

[igor <ig...@iz...>]

I am so ashamed.

This is solved using

XMLUnit.setIgnoreWhitespace(true);

directive.

I am sorry for bothering you with my troubles when I even am not able to 
read the documentation.

Have a nice day (and less spammers of my kind:)

Igor Zemsky

------------------

Hi,

overall the library is working very nice, thanks for it.

But when I run following code, I get as a result that the XMLs do not
match - are not equal. Is this intended behavior? I tried to debug the
source code but it seems to be pretty complex for me, I believe you can
find the cause much faster than me.

// code start

import java.io.IOException;
import org.custommonkey.xmlunit.XMLTestCase;
import org.xml.sax.SAXException;


public static void main(String[] args) {
        XMLTestCase xmlTestCase = new XMLTestCase(){};
        String original = "<a>  </a>"; // here are some space characters
in between the beginning-end tags
        String newVersion =  "<a></a>";
        try {
            xmlTestCase.assertXMLEqual(original, newVersion);
        } catch (SAXException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }

// code end

Best regards

Igor Zemsky

[Xmlunit-general] comparing XMLs containing space characters

[igor <ig...@iz...>]

Hi,

overall the library is working very nice, thanks for it.

But when I run following code, I get as a result that the XMLs do not 
match - are not equal. Is this intended behavior? I tried to debug the 
source code but it seems to be pretty complex for me, I believe you can 
find the cause much faster than me.

// code start

import java.io.IOException;
import org.custommonkey.xmlunit.XMLTestCase;
import org.xml.sax.SAXException;


public static void main(String[] args) {
        XMLTestCase xmlTestCase = new XMLTestCase(){};
        String original = "<a>  </a>"; // here are some space characters 
in between the beginning-end tags
        String newVersion =  "<a></a>";
        try {
            xmlTestCase.assertXMLEqual(original, newVersion);
        } catch (SAXException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }

// code end

Best regards

Igor Zemsky