xmlunit-general — Everything XMLUnit ;0)

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

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

On Wed, 25 Apr 2007, David Carver <dc...@st...> wrote:
>>> This article shows how to pre-compile a schema using JAXP 1.3 api:
>>>
>>> https://jaxp.dev.java.net/article/jaxp-1_3-article.html#Compile_Schema(s)
>>>
>>
>> I will look into it, thanks for the link.
>>
>> This probably should go into XMLUnit 1.2, I'd like to see us
>> finalize 1.1 pretty soon.  There is nothing bad in having frequent
>> releases, more frequent than every four years, that is 8-)
>>
> Yeah, I agree. If I can get some spare time, I'll take an initial
> stab at getting it going.

That would be nice.

> 1.1 Beta seems to be working for us, at least the portions that we
> currently use.

Thanks

        Stefan

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

[David C. <dc...@st...>]

>> This article shows how to pre-compile a schema using JAXP 1.3 api:
>>
>> https://jaxp.dev.java.net/article/jaxp-1_3-article.html#Compile_Schema(s)
>>     
>
> I will look into it, thanks for the link.
>
> This probably should go into XMLUnit 1.2, I'd like to see us finalize
> 1.1 pretty soon.  There is nothing bad in having frequent releases,
> more frequent than every four years, that is 8-)
>   
Yeah, I agree. If I can get some spare time, I'll take an initial stab 
at getting it going. 1.1 Beta seems to be working for us, at least the 
portions that we currently use.

Dave

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

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

On Tue, 24 Apr 2007, David Carver <dc...@st...> wrote:
> Stefan Bodewig wrote:
>> On Tue, 24 Apr 2007, David Carver <dc...@st...> wrote:
>>
>>
>>> I mean making sure that the schema compiles in the schema parser
>>> with out error.  Making sure that the schema conforms to the rules
>>> specified by XML Schemas 1.0.
>>>
>>
>> I see.  How do I do that using the JAXP API?
>>
>>
> This article shows how to pre-compile a schema using JAXP 1.3 api:
> 
> https://jaxp.dev.java.net/article/jaxp-1_3-article.html#Compile_Schema(s)

I will look into it, thanks for the link.

This probably should go into XMLUnit 1.2, I'd like to see us finalize
1.1 pretty soon.  There is nothing bad in having frequent releases,
more frequent than every four years, that is 8-)

Stefan

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

[David C. <dc...@st...>]

Stefan Bodewig wrote:
> On Tue, 24 Apr 2007, David Carver <dc...@st...> wrote:
>
>   
>> I mean making sure that the schema compiles in the schema parser
>> with out error.  Making sure that the schema conforms to the rules
>> specified by XML Schemas 1.0.
>>     
>
> I see.  How do I do that using the JAXP API?
>
>   
This article shows how to pre-compile a schema using JAXP 1.3 api:

https://jaxp.dev.java.net/article/jaxp-1_3-article.html#Compile_Schema(s)

If there are no exceptions tossed during the compilation then the Schema 
is valid, otherwise it isn't.


>> Again, it would be nice to be able to specify on a test basis which
>> Schema Parsers to use for a particular test, and not just instance
>> availability.
>>     
>
> For the instance tests XMLUnit will use the configured SAX parser.
>
>   
That works.

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

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

On Tue, 24 Apr 2007, David Carver <dc...@st...> wrote:

> I mean making sure that the schema compiles in the schema parser
> with out error.  Making sure that the schema conforms to the rules
> specified by XML Schemas 1.0.

I see.  How do I do that using the JAXP API?

> Again, it would be nice to be able to specify on a test basis which
> Schema Parsers to use for a particular test, and not just instance
> availability.

For the instance tests XMLUnit will use the configured SAX parser.

Stefan

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

[David C. <dc...@st...>]

> I see.
>
> The primary use case is that you want to verify a piece of XML by
> testing the results of some given XPath expressions.  What you
> describe is testing an XPath expression by applying it to a given
> document.  So in your case the expression and not the document would
> be under test, right?  I can see how being able to pick a XPath
> implementation might be useful here, agreed.  I'll look into it.
>
>   

Yes, that is one of the use cases.
>> Also, there was mention of schema validation.   Is this just
>> validating an xml instance, or is this validating the xml schema it
>> self?
>>     
>
> Validating the instance, though I must admit that I'm not sure what
> you mean by validating the Schema itself.
>   

I mean making sure that the schema compiles in the schema parser with 
out error.  Making sure that the schema conforms to the rules specified 
by XML Schemas 1.0.    There are two forms of validation, XML Schema 
validation, and then XML Instance validation against a particular 
schemas.   Again, it would be nice to be able to specify on a test basis 
which Schema Parsers to use for a particular test, and not just instance 
availability.   If not, I can always do it manually myself.   I just 
develop XML Schema standards on a day to day basis and it's good to 
verify that the schema itself is valid amongst a wide variety of parsers.

Dave

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

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

On Mon, 23 Apr 2007, David Carver <dc...@st...> wrote:
>> Note that I don't like the XMLUnit with lots of statics API myself
>> either.  I opted for API consistency when I added new things for
>> the 1.1 release, but I plan to experiment with a different approach
>> for XMLUnit 2.0.  Your input is and will be more than welcome.
>
> Well, it seems that if you use the XMLUnit.setNamespaceContext, it
> will carry across when it gets the XPath engine.

It is supposed to 8-)

> I haven't taken a look yet, but is there a way to specify which
> XPath engine to use, as we can with the SAX and DOM parsers?

No.  XMLUnit will pick whatever XPathFactory returns and fall back to
SimpleXpathEngine pre-JAXP-1.3.

I don't think there is a system property to choose a factory or is
there?

> It would be nice to be able to specify either JAXEN, XALAN, or
> SAXON's xpath engines.  Particularly if you are trying to verify
> that something works across the various XPath engines available.

I see.

The primary use case is that you want to verify a piece of XML by
testing the results of some given XPath expressions.  What you
describe is testing an XPath expression by applying it to a given
document.  So in your case the expression and not the document would
be under test, right?  I can see how being able to pick a XPath
implementation might be useful here, agreed.  I'll look into it.

> Also, there was mention of schema validation.   Is this just
> validating an xml instance, or is this validating the xml schema it
> self?

Validating the instance, though I must admit that I'm not sure what
you mean by validating the Schema itself.

<http://xmlunit.sourceforge.net/userguide/html/ar01s04.html#XML%20Schema%20Validation>

Stefan

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

[David C. <dc...@st...>]

> Note that I don't like the XMLUnit with lots of statics API myself
> either.  I opted for API consistency when I added new things for the
> 1.1 release, but I plan to experiment with a different approach for
> XMLUnit 2.0.  Your input is and will be more than welcome.
>   
Well, it seems that if you use the XMLUnit.setNamespaceContext, it will 
carry across when it gets the XPath engine.   I haven't taken a look 
yet, but is there a way to specify which XPath engine to use, as we can 
with the SAX and DOM parsers?   It would be nice to be able to specify 
either JAXEN, XALAN, or SAXON's xpath engines.  Particularly if you are 
trying to verify that something works across the various XPath engines 
available.

Also, there was mention of schema validation.   Is this just validating 
an xml instance, or is this validating the xml schema it self?

Dave

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

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

On Fri, 20 Apr 2007, David Carver <dc...@st...> wrote:

> I guess I would suggest that unless the namespace context is
> specified, that it defaults to the Context of the DOM node being
> processed.

The namespace context is only really needed when you specify a
namespace in your XPath.

The problem with using the mapping of the document under test is that
the mapping can change with every Node.  Without some second guessing
on the XPath expression you cannot know which Node's mapping to use.
Sure, most documents won't change the mapping once it has been
established, but there are others and you can't implement any magic
correctly there.  This is why I opted for explicit mappings.

> If more than one namespace needs to be specified for the XML, then a
> namespace context with all the possible namespaces should be
> provided.

If there is only one namespace, I think you don't need a mapping today
either.  I should probably try 8-)

> I guess I would need to see how having the XMLTestCase with all
> static methods, is going to allow me to set the namespace context,
> and then allow XMLAssert pick up that context.

Note that I don't like the XMLUnit with lots of statics API myself
either.  I opted for API consistency when I added new things for the
1.1 release, but I plan to experiment with a different approach for
XMLUnit 2.0.  Your input is and will be more than welcome.

> Is there a Unit Test for this situation, that I can review that
> shows this working???

Nothing too involved, just a few tests that verify the basic
functionality.  I just realized that
<http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/tests/java/org/custommonkey/xmlunit/AbstractXpathEngineTests.java?revision=170&view=markup>
doesn't use XMLUnit.setNamespaceContext but sets it on the engine
directly (which is OK since it doesn't use newXpathEngine at all).

If you take Exmple 29 from
<http://xmlunit.sourceforge.net/userguide/html/ar01s05.html#Using%20XML%20Namespaces%20in%20XPath%20Selectors>
and move the setNamespaceContext in front of newXpathEngine you'd have
the block of code to use together with XMLAssert.

Stefan

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

[David C. <dc...@st...>]

Never mind I think I answered my own question.  It's been too long since 
I looked at my initial setup code that is underneath my higher level 
interface.  

Where I do the following is where I should also set the NamespaceContext:

        XMLUnit
                
.setControlParser("org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");
        XMLUnit
                
.setTestParser("org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");
        XMLUnit
                
.setSAXParserFactory("org.apache.xerces.jaxp.SAXParserFactoryImpl");
        XMLUnit
                
.setTransformerFactory("org.apache.xalan.processor.TransformerFactoryImpl");

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

[David C. <dc...@st...>]

I guess I would suggest that unless the namespace context is specified, 
that it defaults to the Context of the DOM node being processed.   If 
more than one namespace needs to be specified for the XML, then a 
namespace context with all the possible namespaces should be provided.   
I guess I would need to see how having the XMLTestCase with all static 
methods, is going to allow me to set the namespace context, and then 
allow XMLAssert pick up that context.

Is there a Unit Test for this situation, that I can review that shows 
this working???

Dave

Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

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

On Fri, 20 Apr 2007, David Carver <dc...@st...> wrote:

> There has to be a simplier way to get the namespaces to work.

Maybe.  The most important thing is that it works, though.

> My own custom modfications uses the apache XPathAPI interface, that
> resolves space for you.

We can't go that route, we really need to be parser independent.

> The JAXP 1.3 NamespaceContext is almost a kludge.  While I know it
> allows for parser independant implementations, it also requires you
> to know the namespaces ahead of time.

The URI, and then you can use whichever prefix you want.  What would
be the usecase for XMLUnit where I don't know the Namespace at all but
want to validate an XPath expression that uses the Namespace?

> I figure XMLUnit should at least if you specify that you want to use
> namespaces, that it automatically pulls from the DOM the namespaces
> that have been defined and the prefixes defined in the XML document.

The I'd need to know the prefixes when I specify my XPath expression,
or not?

> As it is now, unless I'm missing something, the XMLAssert static
> functions still aren't namespace aware, because they directly
> instantiate the newXpathEngine() method, which doesn't set a
> NamespaceContext when it is created.

It does, if the context has been set via XMLUnit:

    public static XpathEngine newXpathEngine() {
        ... pick the best available implementation ...
        if (namespaceContext != null) {
            eng.setNamespaceContext(namespaceContext);
        }
        return eng;
    }

> Also, there should be a way for the engine to be established once,
> and reused, instead of being created each time.

I thought about that, but the way it is implemented is consistent with
the handling of parsers and transformers.  You get new instances of
them when you use XMLAssert as well.

If you want to reuse instances you can do so by not using XMLAssert at
all ...

> A few of these enhancements would go a long way to help improve
> useability of the framework.

Hmm, could you please explain how it would do so?  How would your
envisioned API usage look like?

Thanks

        Stefan

Re: [Xmlunit-general] [ANN] XMLUnit for Java 1.1 Beta 1 Released

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

On Fri, 20 Apr 2007, David Carver <dc...@st...> wrote:

> One thing I noticed with the 1.1 beta, is that the
> CountingNodeTester class depends on classes that are in the examples
> package.

There are two CountingNodeTester classes, one in examples and the
other one is a deprecated subclass of it.  I wanted to move the class
from o.c.xmlunit to the examples package but couldn't remove it since
it would break backwards compatibility.

Stefan

[Xmlunit-general] XPath and Namespaces in 1.1 beta

[David C. <dc...@st...>]

There has to be a simplier way to get the namespaces to work.    My own 
custom modfications uses the apache XPathAPI interface, that resolves 
space for you.

The JAXP 1.3 NamespaceContext is almost a kludge.  While I know it 
allows for parser independant implementations, it also requires you to 
know the namespaces ahead of time.   I figure XMLUnit should at least if 
you specify that you want to use namespaces, that it automatically pulls 
from the DOM the namespaces that have been defined and the prefixes 
defined in the XML document.   As it is now, unless I'm missing 
something, the XMLAssert static functions still aren't namespace aware, 
because they directly instantiate the newXpathEngine() method, which 
doesn't set a NamespaceContext when it is created.

Also, there should be a way for the engine to be established once, and 
reused, instead of being created each time.  A few of these enhancements 
would go a long way to help improve useability of the framework.

Dave

Re: [Xmlunit-general] [ANN] XMLUnit for Java 1.1 Beta 1 Released

[David C. <dc...@st...>]

Stefan Bodewig wrote:
> On Thu, 19 Apr 2007, David Carver <dc...@st...> wrote:
>   
>> All the current source changes for Java are in the SVN repository
>> correct?
>>     
>
> Yes.
>
> The beta corresponds to the XMLUnit-Java-1.1-beta1 tag in svn:
> <http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/tags/XMLUnit-Java-1.1-beta1/>
>
> trunk is almost the same, only the version number is different
> (1.1beta2).
>   
Thanks, I was able to get it checked out.  One thing I noticed with the 
1.1 beta, is that the CountingNodeTester class depends on classes that 
are in the examples package.    If they are needed by other classes they 
should be moved out of the examples package.

Dave

Re: [Xmlunit-general] [ANN] XMLUnit for Java 1.1 Beta 1 Released

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

On Thu, 19 Apr 2007, David Carver <dc...@st...> wrote:
> All the current source changes for Java are in the SVN repository
> correct?

Yes.

The beta corresponds to the XMLUnit-Java-1.1-beta1 tag in svn:
<http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/tags/XMLUnit-Java-1.1-beta1/>

trunk is almost the same, only the version number is different
(1.1beta2).

Stefan

Re: [Xmlunit-general] [ANN] XMLUnit for Java 1.1 Beta 1 Released

[David C. <dc...@st...>]

All the current source changes for Java are in the SVN repository correct?

Dave

[Xmlunit-general] [ANN] XMLUnit for Java 1.1 Beta 1 Released

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Today the first Beta release of XMLUnit for Java 1.1 has been
released; download it from
<https://sourceforge.net/project/showfiles.php?group_id=23187&package_id=15921&release_id=502282>

XMLUnit for Java 1.1 fixes all known issues of version 1.0 and adds a
few new features.  The most important changes are:

* Support for XML Namespace in XPath tests

* Support for XML Schema validation

* Support for the JAXP 1.3 XPath engine in javax.xml.xpath

In addition several minor but still useful enhancements have been
made, a full list can be found at
<http://xmlunit.sourceforge.net/userguide/html/apa.html#Changes%201.1>

The release is available as a binary or a source zip archive.  Both
archives contain the new User's Guide in PDF and HTML format.  Please
use the OpenPGP signatures found in
<http://xmlunit.sourceforge.net/checksums/> to verify the integrity of
the released files.

Stefan Bodewig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFGJuu4ohFa4V9ri3IRApXaAKC12jj0AJH1djWGywZjaShr81UHwQCgokyQ
l1x5feM16coJENEbWC2lDBY=
=6vxV
-----END PGP SIGNATURE-----

[Xmlunit-general] User Guide is Finished

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

... well, at least in a state that I'd dare to publish on our website.

Not linked, yet.  The HTML version is
<http://xmlunit.sourceforge.net/users-guide/html/>, the PDF
<http://xmlunit.sourceforge.net/users-guide/XMLUnit-Java.pdf>.

Any feedback is welcome, proof reading by native speakers, CSS
wizardry, whatever.

I don't want to promise too much, but the only things missing for a
first beta is one code change (new Difference) and me getting the
build system for the user's guide into shape.  I'm pretty confident
that we'll see XMLUnit 1.1 beta in April.

Cheers

        Stefan

Re: [Xmlunit-general] Adding a new type of Difference?

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

[I haven't seen David's post to this list so far.  I guess it is
sittting in the moderation queue for some reason.  Unfortunately I am
not a moderator of this list.]

On Wed, 28 Mar 2007, David Carver <dc...@st...> wrote:
>> The later means that in cases where the control document contains
>> nodes not present in the test document the type of difference would
>> change.  This would be a backwards incompatible change (right now
>> you'd get a "element tag name is different") but only affect people
>> using DetailedDiff.
>>
>> What do you think?
>>
>> Stefan
>>
> Any possibility of deprecating the old methods, and creating some
> new methods to handle the new functionality.

The way I envision it there is no new method.  Consider

Control: <a><b/><c/></a>
Test: <a><b/></a>

Today you get two differences from DetailedDiff: (1) "number of
childern on <a> is different" and (2) "expected <c/> but was <b/>".
I'd like to turn the second into "element <c/> not found".

The other way around

Control: <a><b/></a>
Test: <a><b/><c/></a>

only leads to a single difference from DetailedDiff today: (1) "number
of childern on <a> is different".  I'd like to add "element <c/> not
found".

I wouldn't want to touch

Control: <a><b/><c/></a>
Test: <a><b/><d/></a>

where the only difference would be "expected <c> but was <d>".

Stefan

Re: [Xmlunit-general] Adding a new type of Difference?

[David C. <dc...@st...>]

> The later means that in cases where the control document contains
> nodes not present in the test document the type of difference would
> change.  This would be a backwards incompatible change (right now
> you'd get a "element tag name is different") but only affect people
> using DetailedDiff.
>
> What do you think?
>
> Stefan
>   
Any possibility of deprecating the old methods, and creating some new 
methods to handle the new functionality.  That way you can migrate out 
the old ones at a later date, and give people time to make the change.

Dave

[Xmlunit-general] Adding a new type of Difference?

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

Hi,

on the help forum there is a thread started by a user who wants to
highlight all differences between two XML docs in some kind of UI.

He/she is using DetailedDiff and assumes all differences would be
flagged - I agree with this expectation.

A problem arises if the test document contains more nodes than the
control document.  XMLUnit will tell you the number of children is
different on the parent of that node, but there is no difference that
would reference the new node - so there is no programatic way to tell
which node is new.

We already have a Difference for "attribute name not found" and I'd
like to introduce one for "element name not found" and I'd like to
make it work symmetrically.

The later means that in cases where the control document contains
nodes not present in the test document the type of difference would
change.  This would be a backwards incompatible change (right now
you'd get a "element tag name is different") but only affect people
using DetailedDiff.

What do you think?

Stefan

Re: [Xmlunit-general] Documentation Updates

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

On Tue, 27 Mar 2007, James Abley <jam...@gm...> wrote:
> On 27/03/07, Stefan Bodewig <bo...@ap...> wrote:
>> On Tue, 27 Mar 2007, Stefan Bodewig <bo...@ap...> wrote:
>>
>> > I've committed multiple updates to the Docbook docs over the past
>> > days, whenever I do I also refresh the content of
>> > <http://stefan.samaflost.de/xmlunit/docbook/> so you don't need
>> > to install the Docbook toolchain to review the results.
>>
>> Hmm, maybe I should add:
>>
>> * I'm not a native speaker.
> 
> Ihr Englisch ist besser als mein Deutscher.

Thanks.  I assume I have more practice 8-)

>> * I write most of the docs pretty late in the evening or pretty
>> * early in the morning.
> 
> I noticed, judging by the time you send email!

Geek and early bird is a rare combination, I know.

> Looks very good. I feel bad for not having sent in the DocBook stuff
> that I meant to,

Don't worry.

> but I was busy trying to get a new job. That's sorted (upside),

Congrats.

> but I'll probably have less time to do any open-source stuff
> (downside).

Any contribution will be welcome.

> Just one question; you are updating SF.net Subversion with the Docs
> and building them for your own site.

This will change when we do the first XMLUnit 1.1 release or maybe as
soon as the docs are "complete".  I don't want to put the docs on the
sourceforge site with so many blanks still to be filled.

> Maybe rsync the two, or how about maven2 for the xmlunit site?

I'll need integrate doc generation with XMLUnit's build system anyway
and will probably go the rsync over SSH route.

Stefan

Re: [Xmlunit-general] Documentation Updates

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

On 27/03/07, Stefan Bodewig <bo...@ap...> wrote:
> On Tue, 27 Mar 2007, Stefan Bodewig <bo...@ap...> wrote:
>
> > I've committed multiple updates to the Docbook docs over the past
> > days, whenever I do I also refresh the content of
> > <http://stefan.samaflost.de/xmlunit/docbook/> so you don't need to
> > install the Docbook toolchain to review the results.
>
> Hmm, maybe I should add:
>
> * I'm not a native speaker.

Ihr Englisch ist besser als mein Deutscher.

>
> * I write most of the docs pretty late in the evening or pretty early
>   in the morning.

I noticed, judging by the time you send email!

>
> * I haven't even run ispell over the docs, yet.
>
> So any kind of review is more than welcome.

Looks very good. I feel bad for not having sent in the DocBook stuff
that I meant to, but I was busy trying to get a new job. That's sorted
(upside), but I'll probably have less time to do any open-source stuff
(downside).

Just one question; you are updating SF.net Subversion with the Docs
and building them for your own site. Maybe rsync the two, or how about
maven2 for the xmlunit site?

Cheers,

James

>
> Stefan
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general
>

Re: [Xmlunit-general] Trackers Restructured

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

So not waiting to see whether David gets any negative feedback then? ;-)

On 27/03/07, Stefan Bodewig <bo...@ap...> wrote:
> Hi,
>
> after seeing what Dave Saff did over in JUnit I decided it was a good
> idea to close down two of our four trackers.  I moved all issues of
> the "Support Requests" and "Patches" trackers to either "Bugs" and
> "Feature Requests" and closed the former two.
>
> We welcome patches for bug reports and feature requests and at least I
> am not prepared to deal with support requests on three different
> channels - mailing list, forum and a tracker.
>
> At the same time I modified the remaining tracker to send a mail to
> the commits list if one of the items changes - this won't be visible
> to anybody but me right now ;-)
>
> Stefan
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general
>