xmlunit-general — Everything XMLUnit ;0)

[Xmlunit-general] Validation API for XMLUnit 2

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

Hi,

Both current XMLUnit implementations support Validation of XML pieces
against XML Schema defitions or DTDs - in the .NET case this only
works if the instance document contains a Schema or DTD reference and
the reference can be resolved AFAICS.

The Java version has two different validator classes, one based on the
"old" validation model where the document is validated as a side
effect of parsing (similar to the way .NET works) and a different one
using javax.xml.validation - which doesn't do DTDs but in theory
supports RelaxNG and other schema languages.

All three of them return booleans to indicate whether an instance is
valid, the .NET code and the old Java validator provide a single
string message for the validation error(s) - the new Java validator
provides a list of exceptions.

The "new" Java validator can validate schema defitions in addition to
schema instances.  I like this even if I don't know how to implement
it for .NET or for DTDs in Java, yet.

The .NET and old Java code use a model of "one validator per instance
document", the new Java code uses one instance per schema definition.

All in all I tend to prefer the "new" Java API as a model for how
XMLUnit2 should do validation, but I'd rather use a ValidationError
class than a SAXParserException as a holder for the validation errors.

So a first sketch - leaving out things like resolvers for now - could
look like (no public/private qualifiers on attributes, just think .NET
properties or Java getters/setters):

class ValidationError {
    readonly int line; // with a negative constant for UNKNOWN
    readonly int column; // ditto

    readonly String message;
}

.NET knows warnings in addition to errors, I'm not sure how we should
handle them.

class ValidationResult {
    readonly bool valid;
    readonly Iterable/IEnumerable<ValidationError> errors;
}

class Validator {
    String schemaURI; // should that be an URI instead? probably wouldn't
                      // work for DTDs then
    Source[] schemaSources;

    ValidationResult validateSchema();
    ValidationResult validateInstance(Source);
}

Since the Java code will be prettier if it uses different
implementations for DTDs and W3C Schema I suggest to add a factory
method

class Validator {
    static Validator forLanguage(String);
}

using the strings defined in javax.xml.XmlConstants for DTD and W3C
schema.  We may also add a static isLanguageSupported method so people
can probe for e.g. RelaxNG support.  .NET would define a string for
XDR and support DTD, W3C schema and XDR, Java would support DTD (by
parsing) and anything SchemaFactory supports.

Am I on track here?

Stefan

[Xmlunit-general] Custom Exceptions in .NET?

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

Hi,

I've implemented some basic builders for the most common input sources
in trunk (both platforms).

For the Java versions I've not yet wrapped the exceptions that may be
thrown into XMLUnit-specific RuntimeException but will do so like I
did in XMLUnit 1.x.

For the .NET code the main reason for XMLUnit's own exception classes
(checked exceptions) doesn't exist.  Is there still some additional
value in wrapping exceptions in XMLUnit exceptions or do we simply not
handle exceptions like XmlException or IOException at all?

Stefan

[Xmlunit-general] XMLUnit for .NET 0.4 Released

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

This is a maintenance release of XMLUnit for .NET which fixes a few
bugs, in particular:

- order of attributes is ignored, this means there will never be a
  difference of type 4 anymore.

  A new flag in DifferenceConfiguration can be used to turn on the old
  behavior where attribute order was significant.

- xmlns attributes are now no longer treated as normal attributes and
  the namespace of attributes is now sigificant

- comparisions of empty elements with attributes failed.
  I.e. <foo><bar x="1"/></foo> was considered different from
  <foo><bar x="1"></bar></foo>

The binary in this release has been compiled against NUnit 2.4.8, if
you are using a different version of NUnit you will need to compile
XMLUnit yourself.

This is expected to be the last XMLUnit release compatible with .NET
1.1, we plan to develop XMLUnit2 for .NET and java in parallel and
XMLUnit2 will require .NET 2.0 (or later).

Please verify the checksums and signature available from
http://xmlunit.sourceforge.net/checksums/ after you've downloaded the
release.

[Xmlunit-general] XMLUnit2 legal stuff (was Re: SF.net SVN: xmlunit:[303] legal/icla.txt)

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

On 2009-04-27, <bo...@us...> wrote:

> Revision: 303
>           http://xmlunit.svn.sourceforge.net/xmlunit/?rev=303&view=rev
> Author:   bodewig
> Date:     2009-04-27 14:37:27 +0000 (Mon, 27 Apr 2009)

> Log Message:
> -----------
> the Individual Contributors License Agreement

This is Apache's "Individual Contributor's License Agreement" adapted
to talk about XMLUnit instead of the ASF.  At the same time I've
decided to use Version 2.0 of the Apache License for XMLUnit2.

The most important point to potential contributors is that you don't
transfer copyright of your contribution (you mere license it to the
project) and retain all control over it.

We won't accept any contributions to XMLUnit2 without a CLA.  Sorry if
this sounds more hassle than it needs to be, but I prefer to be on the
safe side.

Once I get close to a printer and scanner I'll scan my own CLA and add
it to svn.  I'm going to encrypt it to make things a bit more
difficult for crawlers looking for spam targets, but will share the
encryption key (likely my public OpenPGP key).

I'll do the same to any CLA that I receive either via email (scanned,
we need a real signature) or good old snail mail.

Stefan

Re: [Xmlunit-general] XMLUnit2 - dealing with XML input

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

2009/4/20 Stefan Bodewig <bo...@ap...>:
> Well, it turned out that my ideas are not really that big or even
> complex.
>
> I want a single unified type to represent any type of XML data that
> any part of XMLUnit2 deals with - where any part is the difference
> engine, the validator or the XPath engine.  XMLUnit 1.x has many
> overloads with Document, String, InputStream and InputSource
> parameters and this doesn't really help.
>
> Together with this unified type we'd need adapters and maybe a
> convenient fluent builder.
>
> For Java it turns out such a unified type already exists:
> javax.xml.transform.Source which is used by JAXP's validation API (and
> transformations, obviously) and can be used by JAXP's XPath API in a
> simple way via SAXSource.sourceToInputSource.  The only piece that may
> be a bit more complex to implement would be the difference engine but
> we can always perform an identity transform with a DOMResult as
> target.  The same is true for XPath and a SAXResult.
>
> org.xml.sax.InputSouce could be a choice that would be almost as
> compelling, but it looks as if Source was the way forward in JAXP
> given the validation API and StAXSource in the newer versions.
>
> .NET doesn't really have a type like this.  XmlReader probably gets
> closest but it's a class rather than an interface which may constrict
> some things we'd like to do.
>
> I propose to use something like
>
> public interface ISource {
>    XmlReader Reader {get;}
> }
>
> instead and implement that for XmlDocument, Stream and TextReader.
> The XMLUnit2 APIs would then look similar in that they'd use
> (I)Source.
>
> The builder I envision is somethng along the lines of
>
> Input.fromFile("some/path").withEntityResolver(someResolver).build();
>
> Comments?
>
> Stefan
>

Sounds reasonable. I would love to be able to contribute in terms of
(Java) code but I'm a bit swamped for the foreseeable few months.
Happy to bounce ideas around though.

Cheers,

James

[Xmlunit-general] XMLUnit2 - dealing with XML input

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

Well, it turned out that my ideas are not really that big or even
complex.

I want a single unified type to represent any type of XML data that
any part of XMLUnit2 deals with - where any part is the difference
engine, the validator or the XPath engine.  XMLUnit 1.x has many
overloads with Document, String, InputStream and InputSource
parameters and this doesn't really help.

Together with this unified type we'd need adapters and maybe a
convenient fluent builder.

For Java it turns out such a unified type already exists:
javax.xml.transform.Source which is used by JAXP's validation API (and
transformations, obviously) and can be used by JAXP's XPath API in a
simple way via SAXSource.sourceToInputSource.  The only piece that may
be a bit more complex to implement would be the difference engine but
we can always perform an identity transform with a DOMResult as
target.  The same is true for XPath and a SAXResult.

org.xml.sax.InputSouce could be a choice that would be almost as
compelling, but it looks as if Source was the way forward in JAXP
given the validation API and StAXSource in the newer versions.

.NET doesn't really have a type like this.  XmlReader probably gets
closest but it's a class rather than an interface which may constrict
some things we'd like to do.

I propose to use something like

public interface ISource {
    XmlReader Reader {get;}
}

instead and implement that for XmlDocument, Stream and TextReader.
The XMLUnit2 APIs would then look similar in that they'd use
(I)Source.

The builder I envision is somethng along the lines of

Input.fromFile("some/path").withEntityResolver(someResolver).build();

Comments?

Stefan

[Xmlunit-general] Some XMLUnit2 discussion items

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

This is a list of issues to resolve before we can seriously work on
implementing XMLUnit2, it will ceratainly be incomplete but we can
tackle them as they occur.

I'll list the issues along with my take on them.

>From the top of my head:

* which Java/.NET version should be the baseline?

Java5, .NET 2.0

I'd love to use C# 3.0 even if it just was because of lambdas, but
right now I feel requiring .NET 3.5 would go too far.

* package/namespace names?

net.sf.xmlunit

* which pieces of XMLUnit for Java 1.2 do we want to support?

diff, validation, xpath

I'm personally not interested in dealing with non-well-formed XML,
there are other libraries that solve this well.

The node tester stuff may be interesting but I'm not convinced that
DocumentTraversal is the way to go.  I have some ideas on providing a
Hüet Zipper for the DOM tree which may make things easier here.
Anyway, I'd like to defer that.

Anything XMLUnit2 doesn't do will still be available from the legacy
jar.

* do we want to provide a legacy DLL for XMLUnit.NET?

No.

* do we want to change the license?

I'd be open for a couple of licenses ranging from MIT over Apache
License version 2 to Mozilla or Eclipse but don't see any pressing
need to change the current Apache License 1.1.

I won't accept any form of (L)GPL, no point in even starting a
discussion on that.

* branching - who will be trunk?

There are two options: create a branch for XMLUnit 2 and keep the
trunk at XMLUnit 1.x or create a branch for XMLUnit 1.x and develop
XMLUnit2 on trunk.

I'd go for XMLUnit2 on trunk.

* switch to a different VCS?

Now that sourceforge supports git, mercurial and bazaar do we want to
move away from svn?  I'm on the fence here.  I'm a darcs user and have
been for years so I'm quite familar with the benefits of distributed
VCS over svn, I don't see them apply to XMLUnit's current situation,
though.

If we wanted to use a different VCS, I have no preference for either
of the three hosted at sourceforge as I haven't used any of them
myself.

* which documenation format?

Two years ago I wanted to use LaTeX but went with docbook after some
people on this list said it would be more likely I'd get patches for
docbook.  I never received any patches for the documentation at all,
so I could as well go straight to LaTeX unless I hear good reasons not
to.

* which build system for the .NET version?  NAnt or Visual
  Studio/MSBuild?

I'd keep NAnt support for the folks using Mono but would be OK with
additional VS solutions as long as the NAnt build is kept in sync with
it.

Stefan

[Xmlunit-general] XMLUnit 2

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

Hi,

Changing the way some pieces of XMLUnit work has been on my TODO list
for quite some time, but since that list always grows, I just never
seem to reach the point that I actually *do* it.

A few weeks ago Maxim Filimonov came in and he seems to have the
energy to actually do something - and I don't want to stand in his
way.

The rest of this mail - and likely mails sent by me on this and
related threads later - will contain "I" in many places.  Right now
I'm the sole contributor and I take the liberty to make decisions as I
see fit.  But I don't want to keep this project a one-man show (in
fact if you want to help and have the time to actually do so, speak
up) and will not only listen to feedback but try to find consensus.

Before I discuss more details in separate email threads here is what I
intend to do for XMLUnit2, much of this is not really technical at
all:

* split the Java jar into multiple pieces:

  xmlunit-core:   only depends on the JDK
  xmlunit-junit3: provides custom JUnit3 assert methods on top of
                  xmlunit-core
  xmlunit-junit4: provides custom Java 1.4 assert methods on top of
                  xmlunit-core to use together with JUnit 4.x
  xmlunit-legacy: provide the old API and pieces I don't intend to
                  support in the future on top of xmlunit-core and
                  xmlunit-junit3

* split the .NET DLL into multiple pieces

  xmlunit-core:  only depends on the framework class library
  xmlunit-nunit: provides custom NUnit assert methods on top of
                 xmlunit-core

* keep .NET and Java versions in sync

  This doesn't mean things have to be identical from the API level,
  but close.  For example we may chose to use delegates in .NET where
  the Java version uses one-method interfaces.  .NET will capitalize
  method names and may use properties instead of get/set pairs ...

* try to share tests between .NET and Java versions

* change package/namespace to avoid confusion

* some legal changes (I will forward this mail to Jeff and Tim to
  allow them to chime in), in particular:

  - the old sources - which only live in xmlunit-legacy - won't be
    affected by anthing I list below

  - any new code will be written from scratch

  - the new code won't carry any copyright notice at all

  - before I grant anybody commit access or accept bigger patches I'll
    require a contributor license agreement which will be scanned and
    put into svn.  I'll certainly sign one myself.

    I'll likely use Apache's CLA as a template.

    This is more a way to protect myself and other future contributors
    than anything else.

* design XMLUnit2 in an API-first way

  There are some ideas and I'll start with explaining my ideas of how
  we should specify input for the different pieces of XMLUnit first -
  I hope to get this done over the weekend or early next week.

Stefan

Re: [Xmlunit-general] XmlUnit.net XPathNodeTracker?

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

Would ikvm work here? The only usage I'm aware of is Saxon - I've no
experience with it myself.

2009/3/25 Stefan Bodewig <bo...@ap...>:
> On 2009-03-24, Maxim Filimonov <tpa...@gm...> wrote:
>
>> I plan to use Xml Unit for .net in my current testing of XSLT processing as
>> main testing framework.
>> I have some experience with Java version of Xml Unit after i migrate to .net
>> version i'm shocked a bit that so much difference between java and .net
>> version exists.
>
> Once you dive deeper into it, you'll see that many features of the
> Java version cannot be easily added without rewriting the difference
> engine completely - the Java version uses DOM while the .NET version
> uses a forward only pull parser, which makes things like
> ElementQualifier very hard to implement.
>
> Current svn trunk contains some unreleased fixes for the .NET version,
> BTW.
>
>> Java version is mature and solid and it contains real value to use it.
>> .net version is not mature enough for us at least.
>> I will port Java version of XPathNodeTracker and referenced items to make
>> testing results more valuable.
>> Is anybody interested in this solution to be shared ?
>
> Yes.
>
> There is a task on my ever growing TODO list that says "rewrite
> XMLUnit.NET", but I have very little hope of ever getting there
> without help of more people.
>
> Stefan
>

Things that spring to mind:

1) ikvm. The only usage that I'm aware of is Saxon, but thought I'd
throw it out there.
2) ANTLR. Developed in Java; there is a C# version. Not sure how that
was ported, but given the nature of the project, I'm curious if they
managed to get some source-to-source translation thing going. I'm on
the antlr-users list, so I'll ask there and let you know.

Cheers,

James

Re: [Xmlunit-general] XmlUnit.net XPathNodeTracker?

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

On 2009-03-24, Maxim Filimonov <tpa...@gm...> wrote:

> I plan to use Xml Unit for .net in my current testing of XSLT processing as
> main testing framework.
> I have some experience with Java version of Xml Unit after i migrate to .net
> version i'm shocked a bit that so much difference between java and .net
> version exists.

Once you dive deeper into it, you'll see that many features of the
Java version cannot be easily added without rewriting the difference
engine completely - the Java version uses DOM while the .NET version
uses a forward only pull parser, which makes things like
ElementQualifier very hard to implement.

Current svn trunk contains some unreleased fixes for the .NET version,
BTW.

> Java version is mature and solid and it contains real value to use it.
> .net version is not mature enough for us at least.
> I will port Java version of XPathNodeTracker and referenced items to make
> testing results more valuable.
> Is anybody interested in this solution to be shared ?

Yes.

There is a task on my ever growing TODO list that says "rewrite
XMLUnit.NET", but I have very little hope of ever getting there
without help of more people.

Stefan

[Xmlunit-general] XmlUnit.net XPathNodeTracker?

[Maxim F. <tpa...@gm...>]

Hi everyone.
I plan to use Xml Unit for .net in my current testing of XSLT processing as
main testing framework.
I have some experience with Java version of Xml Unit after i migrate to .net
version i'm shocked a bit that so much difference between java and .net
version exists.
Java version is mature and solid and it contains real value to use it.
.net version is not mature enough for us at least.
I will port Java version of XPathNodeTracker and referenced items to make
testing results more valuable.
Is anybody interested in this solution to be shared ?

Re: [Xmlunit-general] using the RecursiveElementNameAndTextQualifier

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

On 2008-11-11, Edward Kawas <edw...@gm...> wrote:

> Thanks for your prompt reply. I will try and get an extension working and if
> successful, do you want me to send it your way as an example?

Sure, if you'd like to contribute it, I'd certainly add it.  If only
to improve test coverage.

Stefan

Re: [Xmlunit-general] using the RecursiveElementNameAndTextQualifier

[Edward K. <edw...@gm...>]

Thanks for your prompt reply. I will try and get an extension working and if
successful, do you want me to send it your way as an example?

Thanks again,

Eddie

-----Original Message-----
From: Stefan Bodewig [mailto:bo...@ap...] 
Sent: November-11-08 4:57 AM
To: xml...@li...
Subject: Re: [Xmlunit-general] using the
RecursiveElementNameAndTextQualifier

On 2008-11-10, Edward Kawas <edw...@gm...> wrote:

> My question is that I am using the RecursiveElementNameAndTextQualifier
and
> I noticed that if I try to compare 2 documents with one change in the
child
> nodes, then this qualifier works. However, I if I swap > 1 nodes, this
> qualifier seems to fail.

I am surprised that it works for one.  Hmm, no, maybe I'm not.  It
works if you swap the last nodes (Q6PFF9 and Q8VHD0), but not if you
swap the two that are further to the front of the document (B1AR77 and
B1AR78), right?

RecursiveElementNameAndTextQualifier says two elements are to be
compared if the element names and nested texts (down many levels)
match.  It doesn't look at any attribute values.

In the case of Q6PFF9 and Q8VHD0 theit textual contents and the values
of an attribute differ, but XMLunit manages to match the correct
elements to each other by just looking at the textual content.  B1AR77
and B1AR78 only differ in their attribute values,
RecursiveElementNameAndTextQualifier will say the elements can be
compared in the order they appear in since they have the same textual
content.

What you'd need is an ElementQualifier implementation that used
element names and attribute values to determine which elements to
compare to each other.  I'm afraid that no ready-made solution exists
for this, you may want to take RecursiveElementNameAndTextQualifier as
a source of inspiration 8-)

> Also, I have a second question. If I use the
> RecursiveElementNameAndTextQualifier, should I file and place it in my
> project, or is that file guaranteed to persist?

Even in my very theoretical and long overdue ideas of an XMLUnit 2.x
rewrite I'd keep the examples around.  They might move to a different
jar but I don't see any reason to remove them from the distribution.

Stefan

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Xmlunit-general mailing list
Xml...@li...
https://lists.sourceforge.net/lists/listinfo/xmlunit-general

Re: [Xmlunit-general] using the RecursiveElementNameAndTextQualifier

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

On 2008-11-10, Edward Kawas <edw...@gm...> wrote:

> My question is that I am using the RecursiveElementNameAndTextQualifier and
> I noticed that if I try to compare 2 documents with one change in the child
> nodes, then this qualifier works. However, I if I swap > 1 nodes, this
> qualifier seems to fail.

I am surprised that it works for one.  Hmm, no, maybe I'm not.  It
works if you swap the last nodes (Q6PFF9 and Q8VHD0), but not if you
swap the two that are further to the front of the document (B1AR77 and
B1AR78), right?

RecursiveElementNameAndTextQualifier says two elements are to be
compared if the element names and nested texts (down many levels)
match.  It doesn't look at any attribute values.

In the case of Q6PFF9 and Q8VHD0 theit textual contents and the values
of an attribute differ, but XMLunit manages to match the correct
elements to each other by just looking at the textual content.  B1AR77
and B1AR78 only differ in their attribute values,
RecursiveElementNameAndTextQualifier will say the elements can be
compared in the order they appear in since they have the same textual
content.

What you'd need is an ElementQualifier implementation that used
element names and attribute values to determine which elements to
compare to each other.  I'm afraid that no ready-made solution exists
for this, you may want to take RecursiveElementNameAndTextQualifier as
a source of inspiration 8-)

> Also, I have a second question. If I use the
> RecursiveElementNameAndTextQualifier, should I file and place it in my
> project, or is that file guaranteed to persist?

Even in my very theoretical and long overdue ideas of an XMLUnit 2.x
rewrite I'd keep the examples around.  They might move to a different
jar but I don't see any reason to remove them from the distribution.

Stefan

[Xmlunit-general] using the RecursiveElementNameAndTextQualifier

[Edward K. <edw...@gm...>]

Hi,

Before I begin, I would like to thank the authors of this software for
creating a much needed piece of code!

My question is that I am using the RecursiveElementNameAndTextQualifier and
I noticed that if I try to compare 2 documents with one change in the child
nodes, then this qualifier works. However, I if I swap > 1 nodes, this
qualifier seems to fail. I have attached 2 xml docs (the test doc has 2
nodes swapped from the control doc).

My code is: 

	// don't care about ordering or comments, etc
	XMLUnit.setIgnoreAttributeOrder(true);
	XMLUnit.setIgnoreComments(true);
	XMLUnit.setIgnoreWhitespace(true);
	XMLUnit.setIgnoreDiffBetweenTextAndCDATA(true);
	// get the differences
	StringBuilder sb = new StringBuilder();
	// getControlXML & getTestXML get the attached docs
	DetailedDiff myDiff = new DetailedDiff(new Diff(getControlXML(),
getTestXML()));
	// override the qualifier because I don't care about child order
	myDiff.overrideElementQualifier(new
RecursiveElementNameAndTextQualifier());
	List<Difference> differences = myDiff.getAllDifferences();
	for (Difference d : differences)
	    sb.append(d.toString() + "\n");
	System.out.println(sb.toString());

Am I doing something wrong?

Also, I have a second question. If I use the
RecursiveElementNameAndTextQualifier, should I file and place it in my
project, or is that file guaranteed to persist?

Thanks a lot!

Eddie

Re: [Xmlunit-general] Bypass new line characters

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

On Wed, 22 Oct 2008, Jaydeep Ayachit <jay...@pe...> wrote:

> Any idea as how to bypass new line characters? 

sure, just tell XMLUnit to ignore whitespace:
<http://xmlunit.sourceforge.net/userguide/html/ar01s03.html#Whitespace%20Handling>

Stefan

[Xmlunit-general] Bypass new line characters

[Jaydeep A. <jay...@pe...>]

Hello,

 

I have a requirement to compare xml data returned from an api against xml
data saved in file. I am using xmlunit for the same.

 

Xml data returned from api -

 

<?xml
version="1.0"?><VEHICLE_LIST><SCREEN_NAME>FE601019</SCREEN_NAME><SCREEN_NAME
>FE601018</SCREEN_NAME><SCREEN_NAME>CD601015</SCREEN_NAME><SCREEN_NAME>CD601
016</SCREEN_NAME><SCREEN_NAME>CA000382</SCREEN_NAME></VEHICLE_LIST>

 

Xml data from file -

 

<?xml version="1.0"?>

<VEHICLE_LIST>

     <SCREEN_NAME>FE601019</SCREEN_NAME>

     <SCREEN_NAME>FE601018</SCREEN_NAME>

     <SCREEN_NAME>CD601015</SCREEN_NAME>

     <SCREEN_NAME>CD601016</SCREEN_NAME>

     <SCREEN_NAME>CA000382</SCREEN_NAME>

</VEHICLE_LIST>

 

Data from both sources is same except file has extra newline characters
<\n>. These characters are also considered during comparison and hence it
fails.

 

Any idea as how to bypass new line characters? 

One option is to read file and skip all new line characters.

 

Thanks

Jaydeep


DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

Re: [Xmlunit-general] Matching ordered and unordered collections

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

sorry I ddn't respond earlier, I've been on vacation when you sent
your original request and still haven't caught up with everything.

Yes, this is the right forum to use.

On Sat, 26 Jul 2008, Naresh Bhatia <NB...@sa...> wrote:

> I am a newbie to XMLUnit. I was trying to match the following pieces
> of XML where
> 
> 1) forums is an unordered collection for forum objects
> 2) forum is an unordered collection of thread objects
> 3) thread is an ordered collection of message objects

That's a bit too much "unordered" for the built-in and custom
matchers.  you'd need to build your own ElementQualifier since this
goes beyond what even RecursiveElementNameAndTextQualifier can do.

> Control
> =======
> <forums>
>     <forum>
>         <name>forum1</name>
>         <thread>
>             <title>thread11</title>
>             <message>msg111</message>
>             <message>msg112</message>
>         </thread>
>         <thread>
>             <title>thread12</title>
>             <message>msg121</message>
>             <message>msg122</message>
>         </thread>
>     </forum>
>     <forum>
>         <name>forum2</name>
>         <thread>
>             <title>thread21</title>
>             <message>msg211</message>
>             <message>msg212</message>
>         </thread>
>         <thread>
>             <title>thread22</title>
>             <message>msg221</message>
>             <message>msg222</message>
>         </thread>
>     </forum>
> </forums>
> 
> Test
> ====
> <forums>
>     <forum>
>         <name>forum2</name>
>         <thread>
>             <title>thread22</title>
>             <message>msg221</message>
>             <message>msg222</message>
>         </thread>
>         <thread>
>             <title>thread21</title>
>             <message>msg211</message>
>             <message>msg212</message>
>         </thread>
>     </forum>
>     <forum>
>         <name>forum1</name>
>         <thread>
>             <title>thread12</title>
>             <message>msg121</message>
>             <message>msg122</message>
>         </thread>
>         <thread>
>             <title>thread11</title>
>             <message>msg111</message>
>             <message>msg112</message>
>         </thread>
>     </forum>
> </forums>
>  
> 2) What's interesting is that if I take out threads and messages
> from the data above, then diff.similar() returns true.

The forum elements alone would qualify for the recursive qualifier,
but it is restricted to elements that contains only one child that
holds text.  You are simply requesting more from it than it can deal
with.

> 3) Is there a general way to specify ordered/unordered collections
> at different levels of nesting? I am trying to write a testing
> framework for my application and it would be nice to specify the
> matching criteria flexibly.

Try to write a generic Elementqualifier that works for your case and
you'll see that it is way more complex than you think.

That being said, a specialized ElementQualifier would probably be easy
to write (one that only looked at the forum's name and the thread's
title when asked to select the best matching forum/thread.

Unfortunately there is no ready-made solution.

Stefan

Re: [Xmlunit-general] Matching ordered and unordered collections

[Naresh B. <NB...@sa...>]

I have not received a response to my question below for over a month.
Could someone please let me know if this is the right list or should I
be posting somewhere else? XMLUnit is the best piece of software I have
found for XML comparisons, and I would love to adopt it if I can get
some basics out of the way.

Thanks.
Naresh

-----Original Message-----
From: Naresh Bhatia 
Sent: Saturday, July 26, 2008 1:27 PM
To: 'xml...@li...'
Subject: Matching ordered and unordered collections

I am a newbie to XMLUnit. I was trying to match the following pieces of
XML where

1) forums is an unordered collection for forum objects
2) forum is an unordered collection of thread objects
3) thread is an ordered collection of message objects

Control
=======
<forums>
    <forum>
        <name>forum1</name>
        <thread>
            <title>thread11</title>
            <message>msg111</message>
            <message>msg112</message>
        </thread>
        <thread>
            <title>thread12</title>
            <message>msg121</message>
            <message>msg122</message>
        </thread>
    </forum>
    <forum>
        <name>forum2</name>
        <thread>
            <title>thread21</title>
            <message>msg211</message>
            <message>msg212</message>
        </thread>
        <thread>
            <title>thread22</title>
            <message>msg221</message>
            <message>msg222</message>
        </thread>
    </forum>
</forums>

Test
====
<forums>
    <forum>
        <name>forum2</name>
        <thread>
            <title>thread22</title>
            <message>msg221</message>
            <message>msg222</message>
        </thread>
        <thread>
            <title>thread21</title>
            <message>msg211</message>
            <message>msg212</message>
        </thread>
    </forum>
    <forum>
        <name>forum1</name>
        <thread>
            <title>thread12</title>
            <message>msg121</message>
            <message>msg122</message>
        </thread>
        <thread>
            <title>thread11</title>
            <message>msg111</message>
            <message>msg112</message>
        </thread>
    </forum>
</forums>
 
1) What is the best way to specify this in XMLUnit? Here's my attempt:

   Diff diff = new Diff(control, test);
   diff.overrideElementQualifier(new
RecursiveElementNameAndTextQualifier());
   System.out.println(diff.toString());

This prints the following difference (obviously not what I want):

[different] Expected text value 'forum1' but was 'forum2' - comparing
<name ...>forum1</name> at /forums[1]/forum[1]/name[1]/text()[1] to
<name ...>forum2</name> at /forums[1]/forum[1]/name[1]/text()[1]

2) What's interesting is that if I take out threads and messages from
the data above, then diff.similar() returns true. So why does the
addition of threads and messages choke at the forum level?

3) Is there a general way to specify ordered/unordered collections at
different levels of nesting? I am trying to write a testing framework
for my application and it would be nice to specify the matching criteria
flexibly.

Thanks.
Naresh Bhatia

[Xmlunit-general] Matching ordered and unordered collections

[Naresh B. <NB...@sa...>]

I am a newbie to XMLUnit. I was trying to match the following pieces of
XML where

1) forums is an unordered collection for forum objects
2) forum is an unordered collection of thread objects
3) thread is an ordered collection of message objects

Control
=======
<forums>
    <forum>
        <name>forum1</name>
        <thread>
            <title>thread11</title>
            <message>msg111</message>
            <message>msg112</message>
        </thread>
        <thread>
            <title>thread12</title>
            <message>msg121</message>
            <message>msg122</message>
        </thread>
    </forum>
    <forum>
        <name>forum2</name>
        <thread>
            <title>thread21</title>
            <message>msg211</message>
            <message>msg212</message>
        </thread>
        <thread>
            <title>thread22</title>
            <message>msg221</message>
            <message>msg222</message>
        </thread>
    </forum>
</forums>

Test
====
<forums>
    <forum>
        <name>forum2</name>
        <thread>
            <title>thread22</title>
            <message>msg221</message>
            <message>msg222</message>
        </thread>
        <thread>
            <title>thread21</title>
            <message>msg211</message>
            <message>msg212</message>
        </thread>
    </forum>
    <forum>
        <name>forum1</name>
        <thread>
            <title>thread12</title>
            <message>msg121</message>
            <message>msg122</message>
        </thread>
        <thread>
            <title>thread11</title>
            <message>msg111</message>
            <message>msg112</message>
        </thread>
    </forum>
</forums>
 
1) What is the best way to specify this in XMLUnit? Here's my attempt:

   Diff diff = new Diff(control, test);
   diff.overrideElementQualifier(new
RecursiveElementNameAndTextQualifier());
   System.out.println(diff.toString());

This prints the following difference (obviously not what I want):

[different] Expected text value 'forum1' but was 'forum2' - comparing
<name ...>forum1</name> at /forums[1]/forum[1]/name[1]/text()[1] to
<name ...>forum2</name> at /forums[1]/forum[1]/name[1]/text()[1]

2) What's interesting is that if I take out threads and messages from
the data above, then diff.similar() returns true. So why does the
addition of threads and messages choke at the forum level?

3) Is there a general way to specify ordered/unordered collections at
different levels of nesting? I am trying to write a testing framework
for my application and it would be nice to specify the matching criteria
flexibly.

Thanks.
Naresh Bhatia

Re: [Xmlunit-general] Node order and the test for similarity.

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

On Tue, 24 Jun 2008, Aslam Karachiwala <ak...@gm...> wrote:

> Here are 2 documents that Diff & XMLAssert.assertXMLEqual() should
> consider "similar", as I understand it, but they don't.

Order is only irrelevant if XMLUnit knows how to match the
out-of-order nodes against each other.

> The only difference is the order of the <result /> nodes

Not really.

It is the order of result nodes that differ in Text content in a
grandchild - XMLUnit won't dig that deep when deciding which result
Node to compare to which other result Node, unless you explicitly tell
it to.

If you use the example RecursiveElementNameAndTextQualifier from
XMLUnit 1.2 it should work.

Stefan

[Xmlunit-general] Node order and the test for similarity.

[Aslam K. <ak...@gm...>]

Here are 2 documents that Diff & XMLAssert.assertXMLEqual() should consider
"similar", as I understand it, but they don't. The only difference is the
order of the <result /> nodes -- look at the digit at the end of the
respective <uri /> text.

I'm not explicitly setting any XMLUnit config options.

--aslam

<?xml version="1.0"?>
<sparql
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:xs="http://www.w3.org/2001/XMLSchema#"
    xmlns="http://www.w3.org/2005/sparql-results#" >
  <head>
    <variable name="subject"/>
    <variable name="title"/>
  </head>
  <results>
    <result>
      <binding name="subject">
        <uri>http://m3t4.com/test1#dab4</uri>
      </binding>
      <binding name="title">
        <literal>Aaron Fawcett</literal>
      </binding>
    </result>
    <result>
      <binding name="subject">
        <uri>http://m3t4.com/test1#dab5</uri>
      </binding>
      <binding name="title">
        <literal>Aaron Fawcett</literal>
      </binding>
    </result>
  </results>
</sparql>

===============

<?xml version="1.0"?>
<sparql
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:xs="http://www.w3.org/2001/XMLSchema#"
    xmlns="http://www.w3.org/2005/sparql-results#" >
  <head>
    <variable name="subject"/>
    <variable name="title"/>
  </head>
  <results>
    <result>
      <binding name="subject">
        <uri>http://m3t4.com/test1#dab5</uri>
      </binding>
      <binding name="title">
        <literal>Aaron Fawcett</literal>
      </binding>
    </result>
    <result>
      <binding name="subject">
        <uri>http://m3t4.com/test1#dab4</uri>
      </binding>
      <binding name="title">
        <literal>Aaron Fawcett</literal>
      </binding>
    </result>
  </results>
</sparql>

Re: [Xmlunit-general] [ANN] XMLUnit for Java 1.2 Released

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

On Sun, 15 Jun 2008, James Abley <jam...@gm...> wrote:

> Will the new release be made available via Ivy / Maven repositories
> are well?

It has been synced to the central Maven repo now.

Cheers

        Stefan

Re: [Xmlunit-general] Repeated child elements on different levels

[Yves L. <yv...@la...>]

Hi Stefan,

I've already tried the new RecursiveElementNameAndTextQualifier and it solves my problem as it looks like after a first try.

Thanks
Yves

Stefan Bodewig wrote:
> On Tue, 10 Jun 2008, Yves Langisch <yv...@la...> wrote:
> 
>> The problem here is that I have repeating elements on different
>> levels (Group and Category). The order of Groups and Categories is
>> not relevant. I've found the MultiLevelElementNameAndTextQualifier
>> which solves the problem for one level. How can I solve the problem
>> in general (repeating elements on n different levels)?
> 
> This is quite a bit harder than what
> MultiLevelElementNameAndTextQualifier set out to do  I haven't tried
> it but maybe RecursiveElementNameAndTextQualifier from XMLUnit 1.2
> works out of the box (though I doubt it).  In any case it might give
> you a better start for implementing an ElementQualifier yourself.
> 
> Stefan
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general
> 

Re: [Xmlunit-general] Repeated child elements on different levels

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

On Tue, 10 Jun 2008, Yves Langisch <yv...@la...> wrote:

> The problem here is that I have repeating elements on different
> levels (Group and Category). The order of Groups and Categories is
> not relevant. I've found the MultiLevelElementNameAndTextQualifier
> which solves the problem for one level. How can I solve the problem
> in general (repeating elements on n different levels)?

This is quite a bit harder than what
MultiLevelElementNameAndTextQualifier set out to do  I haven't tried
it but maybe RecursiveElementNameAndTextQualifier from XMLUnit 1.2
works out of the box (though I doubt it).  In any case it might give
you a better start for implementing an ElementQualifier yourself.

Stefan