xmlunit-general — Everything XMLUnit ;0)

[Xmlunit-general] XMLUnit Java 1.1 roadmap

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

Here's my current short list of things to do before a 1.1 release:

* move to subversion

* make whitespace consistent inside the sources

* documentation

* add example code that asserts regular expressions on XPath results -
  this would fix the only remaining open issue.

Am I missing something that's important for anybody?

Stefan

[Xmlunit-general] Documentation

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

Hi,

I've always liked the fact that there is a PDF guide to XMLUnit, but I
don't see myself editing rtf files to adapt it to the new features.
Also I'd like to put more emphasis on using the XMLUnit API instead of
using XMLTestCase so I'd have to make some bigger changes and CVS/svn
history of binary files is non-existant.

So I'm looking for ways to create PDF (and maybe HTML) output from a
text format.  The obvious candidates are LaTeX and Docbook, using
Apache Forrest may be an option as well.  I know LaTeX really well, so
it would be my personal preference.  When I last tried Docbook its PDF
output wasn't really pretty and my knowledge of XSL:FO was (and still
is) far too limited to create better stylesheets.

Any opinions?

Stefan

[Xmlunit-general] Making XMLTestCase abstract?

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

Hi,

there is a Feature Request to make XMLTestCase abstract since
Eclipse's (and probably other's) TestRunner sees the class and tries
to run it as a test suite, which fails because it doesn't contain any
test cases.

I turned down the issue with "can't do it because of backwards
compatibility" but after having second and third thoughts I favor
making the class abstract now.

If people extend XMLTestCase they won't be hurt and anybody who
creates an instance of XMLTestCase most likely should better use
XMLAssert.

What do you think?

Stefan

Re: [Xmlunit-general] XPath/Namespace API changed

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

On Wed, 17 Jan 2007, James Abley <jam...@gm...> wrote:
> On 16/01/07, Stefan Bodewig <bo...@ap...> wrote:

>> I can't say that I like all the statics in XMLUnit too much [...]
> 
> +1 about all the statics. My patch also demonstrated that if you do
> set a static like this, you may need remember to use the tearDown()
> method in your TestCase to unset / clear it afterwards. That's
> caught me out a few times.

Too true.  Still they are here to stay, at least for XMLUnit 1.1.

The blurry picture of XMLUnit 2.0 in my mind doesn't rely on them,
though ;-)

Stefan

Re: [Xmlunit-general] XPath/Namespace API changed

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

On 16/01/07, Stefan Bodewig <bo...@ap...> wrote:
> Hi all,
>
> after looking through James' patch for XML Schema validation I
> realized that he was doing a few things differently from my namespace
> patch for XPath.  Namely he was adding a property to the XMLUnit class
> while I overloaded tons of assertion methods in both XMLAssert and
> XMLTestCase.  James' approach is far more in line with the XMLUnit 1.0
> codebase than mine.
>
> I can't say that I like all the statics in XMLUnit too much but I
> figured that a consistent API (or "conceptual integrity" if you want
> to call it that) is more important than my personal preferences here.

+1 about all the statics. My patch also demonstrated that if you do
set a static like this, you may need remember to use the tearDown()
method in your TestCase to unset / clear it afterwards. That's caught
me out a few times.

>
> Accordingly I've removed all the overloads and introduced a static
> xpathNamespaceContext property (with getters and setters) to XMLUnit.
>
> Stefan
>
> --
> http://stefan.samaflost.de/
>
> -------------------------------------------------------------------------
> 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
>

[Xmlunit-general] XPath/Namespace API changed

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

Hi all,

after looking through James' patch for XML Schema validation I
realized that he was doing a few things differently from my namespace
patch for XPath.  Namely he was adding a property to the XMLUnit class
while I overloaded tons of assertion methods in both XMLAssert and
XMLTestCase.  James' approach is far more in line with the XMLUnit 1.0
codebase than mine.

I can't say that I like all the statics in XMLUnit too much but I
figured that a consistent API (or "conceptual integrity" if you want
to call it that) is more important than my personal preferences here.

Accordingly I've removed all the overloads and introduced a static
xpathNamespaceContext property (with getters and setters) to XMLUnit.

Stefan

-- 
http://stefan.samaflost.de/

Re: [Xmlunit-general] Schema Validation patch development

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

On 08/01/07, James Abley <jam...@gm...> wrote:
> Initial patch up on sourceforge. There are still a few bits I'd like
> to improve, but I was hoping for some peer review.
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1630204&group_id=23187&atid=377770
>
> The usage of the new code is expected in the new tests added to

That meant to say "The usage of the new code is demonstrated by", but
I had just put down a paper on JMock
(http://www.mockobjects.com/files/evolving_an_edsl.ooplsa2006.pdf), so
there was a little disconnect between what I was writing and thinking
about!

> test_Validator. I think that maybe the setSchemaLocation method
> belongs on the XMLUnit class, and that should expose a static method
> for accessing them (using xml-commons resolver or a HashMap
> internally) but I'm haven't had a chance to look at xml-commons
> resolver yet to see whether that feels like a good idea.
>
> Comments welcome.
>
> Cheers,
>
> James
>
> On 05/01/07, James Abley <jam...@gm...> wrote:
> > On 05/01/07, Stefan Bodewig <bo...@ap...> wrote:
> > > On Tue, 2 Jan 2007, James Abley <jam...@gm...> wrote:
> > > > On 22/12/06, Stefan Bodewig <bo...@ap...> wrote:
> > > >> On Thu, 21 Dec 2006, James Abley <jam...@gm...> wrote:
> > > >>
> > > >> > I'm writing a patch for consideration that will handle schema
> > > >> > validation.
> > > >>
> > > >> [please use CVS diff to create patches, it is easier to see what
> > > >> has changed that way]
> > > >
> > > > Will do - I'm just TDDing the feature at the moment and wanted to
> > > > give a little context.
> > >
> > > That's fine.  Thank you.
> > >
> > > >> > In developing the tests for this patch though, I seem to have hit
> > > >> > a bug, and was hoping someone could help me see what I'm doing
> > > >> > wrong.  The below tests fail, although I don't think they
> > > >> > should. I can't see what properties I should be setting that
> > > >> > would cause it to pass.
> > > >>
> > > >> >     private String expected = "<root
> > > >> >     xmlns='http://www.example.com/xmlns/example'" + "
> > > >> >         + xmlns:xsi='http://exampe.com/xmlns/not/schema-instance/namespace'/>";;
> > > >> >     private String actual =  "<root xmlns='http://www.example.com/xmlns/example' />";
> > > >>
> > > >> Why do you expect them to be different?  The
> > > >> http://exampe.com/xmlns/not/schema-instance/namespace is never
> > > >> used.
> > > >>
> > > >
> > > > Well, because it has the namespace declaration and to my current way
> > > > of thinking, that's just an attribute with special semantics.
> > >
> > > The way XMLUnit treats it it is not an attribute at all.  This has a
> > > few benefits like allowing to documents to be equal if they use the
> > > same namespaces but chose different prefixes for example.
> > >
> > > If you declare a namespace but never use it, this will never be seen
> > > by XMLUnit since (as you've seen) this doesn't affect the DOM tree at
> > > all.
> > >
> > > Do you think this is a problem?
> >
> > It is a little annoying when I'm trying to write comprehensive tests.
> > I've got around it by adding a flag to XMLUnit that prevents any xmlns
> > attributes from being ignored, but I would probably want to do that in
> > a more robust fashion as you suggest. If namespaces are being
> > compared, then  (probably) the namespace name is the important thing
> > to compare, rather than the prefixes. I'll write some tests around
> > this area and see how it goes (in a separate patch though).
> >
> > >
> > > > I just realised that the mails on this list don't have the
> > > > Reply-To header set to the mailing list, hence the reason I've been
> > > > replying to individuals rather than the list. Might it be possible
> > > > to alter that?
> > >
> > > I'll note that setting ot not setting Reply-To headers is the subject
> > > of heated discussions (just do a search for "reply-to considered
> > > harmful" with your favorite search engine).  Fortunately I use a MUA
> > > that deals with either way so I'm pretty indifferent.
> > >
> > > I don't have karma to change that setting, though.  Jeff?
> >
> > I'm using GMail for this list at the moment. I'll have a look for
> > Greasemonkey stuff to work around my habit of just hitting reply to
> > list emails, otherwise, I'll just have to be more careful!
> >
> > >
> > > Cheers
> > >
> > >         Stefan
> > >
> >
> > An initial draft of the patch is done; I'm just writing more tests
> > around some serialization, so I'll create a patch on sourceforge
> > hopefully this weekend.
> >
> > Cheers,
> >
> > James
> >
>

Re: [Xmlunit-general] Schema Validation patch development

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

Initial patch up on sourceforge. There are still a few bits I'd like
to improve, but I was hoping for some peer review.

http://sourceforge.net/tracker/index.php?func=detail&aid=1630204&group_id=23187&atid=377770

The usage of the new code is expected in the new tests added to
test_Validator. I think that maybe the setSchemaLocation method
belongs on the XMLUnit class, and that should expose a static method
for accessing them (using xml-commons resolver or a HashMap
internally) but I'm haven't had a chance to look at xml-commons
resolver yet to see whether that feels like a good idea.

Comments welcome.

Cheers,

James

On 05/01/07, James Abley <jam...@gm...> wrote:
> On 05/01/07, Stefan Bodewig <bo...@ap...> wrote:
> > On Tue, 2 Jan 2007, James Abley <jam...@gm...> wrote:
> > > On 22/12/06, Stefan Bodewig <bo...@ap...> wrote:
> > >> On Thu, 21 Dec 2006, James Abley <jam...@gm...> wrote:
> > >>
> > >> > I'm writing a patch for consideration that will handle schema
> > >> > validation.
> > >>
> > >> [please use CVS diff to create patches, it is easier to see what
> > >> has changed that way]
> > >
> > > Will do - I'm just TDDing the feature at the moment and wanted to
> > > give a little context.
> >
> > That's fine.  Thank you.
> >
> > >> > In developing the tests for this patch though, I seem to have hit
> > >> > a bug, and was hoping someone could help me see what I'm doing
> > >> > wrong.  The below tests fail, although I don't think they
> > >> > should. I can't see what properties I should be setting that
> > >> > would cause it to pass.
> > >>
> > >> >     private String expected = "<root
> > >> >     xmlns='http://www.example.com/xmlns/example'" + "
> > >> >         + xmlns:xsi='http://exampe.com/xmlns/not/schema-instance/namespace'/>";;
> > >> >     private String actual =  "<root xmlns='http://www.example.com/xmlns/example' />";
> > >>
> > >> Why do you expect them to be different?  The
> > >> http://exampe.com/xmlns/not/schema-instance/namespace is never
> > >> used.
> > >>
> > >
> > > Well, because it has the namespace declaration and to my current way
> > > of thinking, that's just an attribute with special semantics.
> >
> > The way XMLUnit treats it it is not an attribute at all.  This has a
> > few benefits like allowing to documents to be equal if they use the
> > same namespaces but chose different prefixes for example.
> >
> > If you declare a namespace but never use it, this will never be seen
> > by XMLUnit since (as you've seen) this doesn't affect the DOM tree at
> > all.
> >
> > Do you think this is a problem?
>
> It is a little annoying when I'm trying to write comprehensive tests.
> I've got around it by adding a flag to XMLUnit that prevents any xmlns
> attributes from being ignored, but I would probably want to do that in
> a more robust fashion as you suggest. If namespaces are being
> compared, then  (probably) the namespace name is the important thing
> to compare, rather than the prefixes. I'll write some tests around
> this area and see how it goes (in a separate patch though).
>
> >
> > > I just realised that the mails on this list don't have the
> > > Reply-To header set to the mailing list, hence the reason I've been
> > > replying to individuals rather than the list. Might it be possible
> > > to alter that?
> >
> > I'll note that setting ot not setting Reply-To headers is the subject
> > of heated discussions (just do a search for "reply-to considered
> > harmful" with your favorite search engine).  Fortunately I use a MUA
> > that deals with either way so I'm pretty indifferent.
> >
> > I don't have karma to change that setting, though.  Jeff?
>
> I'm using GMail for this list at the moment. I'll have a look for
> Greasemonkey stuff to work around my habit of just hitting reply to
> list emails, otherwise, I'll just have to be more careful!
>
> >
> > Cheers
> >
> >         Stefan
> >
>
> An initial draft of the patch is done; I'm just writing more tests
> around some serialization, so I'll create a patch on sourceforge
> hopefully this weekend.
>
> Cheers,
>
> James
>

Re: [Xmlunit-general] Schema Validation patch development

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

On 05/01/07, Stefan Bodewig <bo...@ap...> wrote:
> On Tue, 2 Jan 2007, James Abley <jam...@gm...> wrote:
> > On 22/12/06, Stefan Bodewig <bo...@ap...> wrote:
> >> On Thu, 21 Dec 2006, James Abley <jam...@gm...> wrote:
> >>
> >> > I'm writing a patch for consideration that will handle schema
> >> > validation.
> >>
> >> [please use CVS diff to create patches, it is easier to see what
> >> has changed that way]
> >
> > Will do - I'm just TDDing the feature at the moment and wanted to
> > give a little context.
>
> That's fine.  Thank you.
>
> >> > In developing the tests for this patch though, I seem to have hit
> >> > a bug, and was hoping someone could help me see what I'm doing
> >> > wrong.  The below tests fail, although I don't think they
> >> > should. I can't see what properties I should be setting that
> >> > would cause it to pass.
> >>
> >> >     private String expected = "<root
> >> >     xmlns='http://www.example.com/xmlns/example'" + "
> >> >         + xmlns:xsi='http://exampe.com/xmlns/not/schema-instance/namespace'/>";;
> >> >     private String actual =  "<root xmlns='http://www.example.com/xmlns/example' />";
> >>
> >> Why do you expect them to be different?  The
> >> http://exampe.com/xmlns/not/schema-instance/namespace is never
> >> used.
> >>
> >
> > Well, because it has the namespace declaration and to my current way
> > of thinking, that's just an attribute with special semantics.
>
> The way XMLUnit treats it it is not an attribute at all.  This has a
> few benefits like allowing to documents to be equal if they use the
> same namespaces but chose different prefixes for example.
>
> If you declare a namespace but never use it, this will never be seen
> by XMLUnit since (as you've seen) this doesn't affect the DOM tree at
> all.
>
> Do you think this is a problem?

It is a little annoying when I'm trying to write comprehensive tests.
I've got around it by adding a flag to XMLUnit that prevents any xmlns
attributes from being ignored, but I would probably want to do that in
a more robust fashion as you suggest. If namespaces are being
compared, then  (probably) the namespace name is the important thing
to compare, rather than the prefixes. I'll write some tests around
this area and see how it goes (in a separate patch though).

>
> > I just realised that the mails on this list don't have the
> > Reply-To header set to the mailing list, hence the reason I've been
> > replying to individuals rather than the list. Might it be possible
> > to alter that?
>
> I'll note that setting ot not setting Reply-To headers is the subject
> of heated discussions (just do a search for "reply-to considered
> harmful" with your favorite search engine).  Fortunately I use a MUA
> that deals with either way so I'm pretty indifferent.
>
> I don't have karma to change that setting, though.  Jeff?

I'm using GMail for this list at the moment. I'll have a look for
Greasemonkey stuff to work around my habit of just hitting reply to
list emails, otherwise, I'll just have to be more careful!

>
> Cheers
>
>         Stefan
>

An initial draft of the patch is done; I'm just writing more tests
around some serialization, so I'll create a patch on sourceforge
hopefully this weekend.

Cheers,

James

Re: [Xmlunit-general] Schema Validation patch development

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

On Tue, 2 Jan 2007, James Abley <jam...@gm...> wrote:
> On 22/12/06, Stefan Bodewig <bo...@ap...> wrote:
>> On Thu, 21 Dec 2006, James Abley <jam...@gm...> wrote:
>>
>> > I'm writing a patch for consideration that will handle schema
>> > validation.
>>
>> [please use CVS diff to create patches, it is easier to see what
>> has changed that way]
> 
> Will do - I'm just TDDing the feature at the moment and wanted to
> give a little context.

That's fine.  Thank you.

>> > In developing the tests for this patch though, I seem to have hit
>> > a bug, and was hoping someone could help me see what I'm doing
>> > wrong.  The below tests fail, although I don't think they
>> > should. I can't see what properties I should be setting that
>> > would cause it to pass.
>>
>> >     private String expected = "<root
>> >     xmlns='http://www.example.com/xmlns/example'" + "
>> >         + xmlns:xsi='http://exampe.com/xmlns/not/schema-instance/namespace'/>";;
>> >     private String actual =  "<root xmlns='http://www.example.com/xmlns/example' />";
>>
>> Why do you expect them to be different?  The
>> http://exampe.com/xmlns/not/schema-instance/namespace is never
>> used.
>>
> 
> Well, because it has the namespace declaration and to my current way
> of thinking, that's just an attribute with special semantics.

The way XMLUnit treats it it is not an attribute at all.  This has a
few benefits like allowing to documents to be equal if they use the
same namespaces but chose different prefixes for example.

If you declare a namespace but never use it, this will never be seen
by XMLUnit since (as you've seen) this doesn't affect the DOM tree at
all.

Do you think this is a problem?

> I just realised that the mails on this list don't have the
> Reply-To header set to the mailing list, hence the reason I've been
> replying to individuals rather than the list. Might it be possible
> to alter that?

I'll note that setting ot not setting Reply-To headers is the subject
of heated discussions (just do a search for "reply-to considered
harmful" with your favorite search engine).  Fortunately I use a MUA
that deals with either way so I'm pretty indifferent.

I don't have karma to change that setting, though.  Jeff?

Cheers

        Stefan

Re: [Xmlunit-general] Schema Validation patch development

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

This bounced, so trying again.

---------- Forwarded message ----------
From: James Abley <jam...@gm...>
Date: 24-Dec-2006 09:49
Subject: Re: [Xmlunit-general] Schema Validation patch development
To: xml...@li...


On 22/12/06, Stefan Bodewig <bo...@ap...> wrote:
> On Thu, 21 Dec 2006, James Abley <jam...@gm...> wrote:
>
> > I'm writing a patch for consideration that will handle schema
> > validation.
>
> [please use CVS diff to create patches, it is easier to see what has
> changed that way]

Will do - I'm just TDDing the feature at the moment and wanted to give
a little context.

>
> > So I would like to set some properties on a Validator like this:
> >
> > validator = new Validator(new FileReader(xmlFile));
> > validator.setSchemaNamespace("http://www.example.com/xmlns/books");
> > validator.setSchemaURL(xsdFile.toURL());
> > validator.useXMLSchema(true);
> >
> > validator.assertIsValid();
>
> This is something you'd use a catalog for. See OASIS[1] and the XML
> resolver in xml-commons at Apache.  Ant supports a simple Map based
> catalog internally as well as one based on the XML resolver.  I was
> thinking about adding this in a similar way to XMLUnit.

Agreed. It will probably get to that level of complexity once I've got
an initial implementation in place.

>
> > This is what my patch is aiming to provide. Comments on the API and
> > intended usage are welcome.
>
> rather than pairs of setSchemaNamespace/setSchemaURI I'd prefer a
> single method, something like
>
> public void setSchemaLocation(String nsURI, URL nsURL)
>
> or some kind of Map or - see above - a full catalog implemention.

As above - I'm just getting the basic refactoring and API change in
for now, but the catalog would be my preferred full implementation.

>
> > In developing the tests for this patch though, I seem to have hit a
> > bug, and was hoping someone could help me see what I'm doing wrong.
> > The below tests fail, although I don't think they should. I can't
> > see what properties I should be setting that would cause it to pass.
>
> >     private String expected = "<root xmlns='http://www.example.com/xmlns/example'" + "
> >         + xmlns:xsi='http://exampe.com/xmlns/not/schema-instance/namespace'/>";;
> >     private String actual =  "<root xmlns='http://www.example.com/xmlns/example' />";
>
> Why do you expect them to be different?  The
> http://exampe.com/xmlns/not/schema-instance/namespace is never used.
>

Well, because it has the namespace declaration and to my current way
of thinking, that's just an attribute with special semantics. I think
I'll need to dive into the XML (1.0 only for now) and XML Namespaces
specs to see what they discuss and maybe re-evaluate my defintion of
equality in this case.

As part of my current implementation, it examines the XML that's being
validated for the standard schema instance namespace and a
schemaLocation attribute in that namespace, which the parser can use
as a hint when doing schema validation.

One of my tests was checking that the namespace declaration was added
correctly to the document if it's not already present, but xmlunit
doesn't suppport my assumption of how it would behave. I'm also
looking at the current implementation and it does a DOM comparison,
and maybe a SAX-record-and-replay implementation would allow more
options to be configured for this, similar to the way oXygen allows
XML diff options. That would be a bigger change though!

Cheers,

James


PS - just realised that the mails on this list don't have the Reply-To
header set to the mailing list, hence the reason I've been replying to
individuals rather than the list. Might it be possible to alter that?

> Cheers
>
>        Stefan
>
> Footnotes:
> [1]  http://www.oasis-open.org/committees/entity/spec-2001-08-06.html
>
>
> -------------------------------------------------------------------------
> 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] Schema Validation patch development

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

On Thu, 21 Dec 2006, James Abley <jam...@gm...> wrote:

> I'm writing a patch for consideration that will handle schema
> validation.

[please use CVS diff to create patches, it is easier to see what has
changed that way]

> So I would like to set some properties on a Validator like this:
> 
> validator = new Validator(new FileReader(xmlFile));
> validator.setSchemaNamespace("http://www.example.com/xmlns/books");
> validator.setSchemaURL(xsdFile.toURL());
> validator.useXMLSchema(true);
> 
> validator.assertIsValid();

This is something you'd use a catalog for. See OASIS[1] and the XML
resolver in xml-commons at Apache.  Ant supports a simple Map based
catalog internally as well as one based on the XML resolver.  I was
thinking about adding this in a similar way to XMLUnit.

> This is what my patch is aiming to provide. Comments on the API and
> intended usage are welcome.

rather than pairs of setSchemaNamespace/setSchemaURI I'd prefer a
single method, something like

public void setSchemaLocation(String nsURI, URL nsURL)

or some kind of Map or - see above - a full catalog implemention.

> In developing the tests for this patch though, I seem to have hit a
> bug, and was hoping someone could help me see what I'm doing wrong.
> The below tests fail, although I don't think they should. I can't
> see what properties I should be setting that would cause it to pass.

>     private String expected = "<root xmlns='http://www.example.com/xmlns/example'" + "
>         + xmlns:xsi='http://exampe.com/xmlns/not/schema-instance/namespace'/>";;
>     private String actual =  "<root xmlns='http://www.example.com/xmlns/example' />";

Why do you expect them to be different?  The
http://exampe.com/xmlns/not/schema-instance/namespace is never used.

Cheers

        Stefan

Footnotes: 
[1]  http://www.oasis-open.org/committees/entity/spec-2001-08-06.html

[Xmlunit-general] XPath assertions now support XML namespaces

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

Hi all,

this is just a heads up that I've added XML namespace support to
XMLUnit's XPath engines (and the assertions).

I've added a pretty simple NamespaceContext interface with a Map based
default implementation.  An instance of this needs to be injected into
the engine or passed to the assertion methods.

The implementation of namespace support in SimpleXpathEngine is based
on the patch provided by Matthew L Daniel that was appended to issue
953445 - basically all supported namespaces get declared on the XSLT
stylesheet used to extract the XPath result.  For the JAXP 1.3 version
I wrote an adapter from our NamespaceContext tp the
javax.xml.namespace inteface.

Stefan

[Xmlunit-general] Schema Validation patch development

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

I'm writing a patch for consideration that will handle schema validation.

My use case is as follows:

An XML document is generated in some fashion, but it does not contain

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="somenamespace somelocation"

So I would like to set some properties on a Validator like this:

validator = new Validator(new FileReader(xmlFile));
validator.setSchemaNamespace("http://www.example.com/xmlns/books");
validator.setSchemaURL(xsdFile.toURL());
validator.useXMLSchema(true);

validator.assertIsValid();

This is what my patch is aiming to provide. Comments on the API and
intended usage are welcome.

In developing the tests for this patch though, I seem to have hit a
bug, and was hoping someone could help me see what I'm doing wrong.
The below tests fail, although I don't think they should. I can't see
what properties I should be setting that would cause it to pass.


import org.custommonkey.xmlunit.DetailedDiff;
import org.custommonkey.xmlunit.Diff;
import org.custommonkey.xmlunit.XMLTestCase;

public class XMLUnitNamespaceTestCase extends XMLTestCase {

    private String expected = "<root
xmlns='http://www.example.com/xmlns/example'"
        + " xmlns:xsi='http://exampe.com/xmlns/not/schema-instance/namespace'
/>";;
    private String actual =  "<root
xmlns='http://www.example.com/xmlns/example' />";

    public void testNamespaceDifferencesFailViaAssertXMLMethod()
throws Exception {
        assertXMLNotEqual(expected, actual);
    }

    public void testNamespaceDifferencesFailViaDetailedDiff() throws Exception {
        Diff diff = compareXML(expected, actual);
        DetailedDiff detailedDiff = new DetailedDiff(diff);
        assertFalse(detailedDiff.similar());
    }
}

Cheers,

James

Re: [Xmlunit-general] Fwd: Under development again

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

On Mon, 18 Dec 2006, James Abley <jam...@gm...> wrote:
> 
> Some people are still listening!

Good to know 8-)

> On 16/12/06, Stefan Bodewig <bo...@ap...> wrote:

>> For the time being I've spent more time on the Java codebase since
>> this is the one I was more familiar with.  I started fixing a few
>> of the open bugs and by now managed to make XMLUnit pass all its
>> test under JDK 1.5 and 1.6 as well.  In order to do that I've added
>> to SimpleXpathEngine a JAXP 1.3 implementation that gets used under
>> the covers if it is available.
> 
> It sounds like you've been busy!

Some of the fixed bugs really have been fruits hanging very very low ;-)

>> My short term goal is to add XML Schema validation and XML
>> namespace support for XPath assertions,
> 
> Sounds good. In case you're after contributions, I did implement W3C
> Schema validation a while back, and I think it could be worked quite
> happily into a patch. [1]

A patch would be very much appreciated.  I was thinking about
"borrowing" Ant's catalog resolver code so that we could use the an
Apache XML resolver based OASIS Catalog strategy for resolving
entities and schema locations.

>> Certain parts of XMLUnit won't see much love during that process,
>> in particular the classes that support working on good old HTML
>> might better be replaced by something like JTidy in the tests.
> 
> Or Neko? I haven't compared them lately, but might be worth doing.
> HTTPUnit allows Neko or JTidy to be plugged in.

What I was trying to say was that IMHO people should be running JTidy
(or neko) over their input before passing it to XMLUnit rather than
using XMLUnit's TolerantSAXParser - I may be wrong.

>> If anybody thinks that the deprecated methods should not be removed
>> before the next release, please speak up now.
> 
> Depends what's being removed. Presumably this is in HEAD currently?

I'd like to remove all the methods from XMLTestCase that have been
deprecated in 1.0.  Not that many.

>> I'm a bit undecided on dealing with TransformerException and
>> SAXExceptions - should I wrap them in RuntimeExceptions as well or
>> do we expect tests to gracefully deal with invalid XML input?
> 
> I haven't written / come across any tests where I would expect them
> to handle this. IMHO, invalid XML has always been considered a
> problem in the test environment, rather than something specifically
> tested for.  That said, might be worth defining a subclass of
> RuntimeException so that client tests can do the following:

I've already introduced this strategy when I removed the
ParserConfigurationException.  The later gets wrapped in a
ConfigurationException which extends XMLUnitRuntimeException which
extends RuntimeException.

Maybe we need to treat control and test XML differently?  Control
documents should never be invalid, while test documents might be.

> I'll check out the source and see if I'm suitably inspired to pitch
> in.

I'm looking forward to more suggestions.

Stefan

[Xmlunit-general] Fwd: Under development again

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

Oops - hit reply rather than reply all. Sorry.

---------- Forwarded message ----------
From: James Abley <jam...@gm...>
Date: 16-Dec-2006 21:21
Subject: Re: [Xmlunit-general] Under development again
To: Stefan Bodewig <bo...@ap...>


Hi Stefan,

Some people are still listening! I'm very happy to hear that you're
involved; I know you from the ANT list.

On 16/12/06, Stefan Bodewig <bo...@ap...> wrote:
> Hi all,
>
> just in case there still is anybody listening I thought I'd better
> give you a heads up, now that I start breaking everybody's code 8-)
>
> A few months ago I asked Tim and Jeff whether they'd be around to
> accept a few patches and Jeff was kind enough to give me commit
> access.
>
> Back then my primary interest was - and still is - to get the .NET
> version into shape, in particular I'd like to make it work with more
> recent versions of NUnit and the .NET framework (as well as Mono).

Not of interest to me right now. I don't use .NET.

>
> For the time being I've spent more time on the Java codebase since
> this is the one I was more familiar with.  I started fixing a few of
> the open bugs and by now managed to make XMLUnit pass all its test
> under JDK 1.5 and 1.6 as well.  In order to do that I've added to
> SimpleXpathEngine a JAXP 1.3 implementation that gets used under the
> covers if it is available.
>

It sounds like you've been busy!

> My short term goal is to add XML Schema validation and XML namespace
> support for XPath assertions, which should mean I'd have addressed
> almost all open issues in the trackers.  Once done I'd like to do a
> 1.1 release of XMLUnit/Java - and start working on the .NET version
> after that.  Any objections?
>

Sounds good. In case you're after contributions, I did implement W3C
Schema validation a while back, and I think it could be worked quite
happily into a patch. [1]

> Also I'd like to move to subversion sooner rather than later.

+1

>
> Longer term I'd like to break up XMLUnit a bit more.  The XML diff
> engine is usable standalone and I'd like to see it as a first class
> citizen with the *Unit test framework classes just using them.

again, +1. It would be good (although I haven't needed it recently) to
have this more readily available to Java developers.

>
> Speaking of *Unit, I want to add support for JUnit4 style assertions
> (actually Java 1.4 style) and maybe TestNG on the Java side and look
> at the stuff Peli has done for the MBUnit integration on the .NET
> side.  Support for Team Test might be an option there as well.
>
> Certain parts of XMLUnit won't see much love during that process, in
> particular the classes that support working on good old HTML might
> better be replaced by something like JTidy in the tests.

Or Neko? I haven't compared them lately, but might be worth doing.
HTTPUnit allows Neko or JTidy to be plugged in.

>
> In general I want to keep stuff backwards compatible - those who know
> my work on Ant know that I can get pretty paranoid when it comes to
> BWC - but I'll be breaking things every once in a while.
>
> If anybody thinks that the deprecated methods should not be removed
> before the next release, please speak up now.

Depends what's being removed. Presumably this is in HEAD currently?

>
> I started to refactor parts of the exception handling.  Any
> ParserConfigurationException or TransformerConfigurationException now
> gets wrapped in a RuntimeException - you cannot recover from that
> anyway.  I'll probably try to remove IOException from all
> methods/constructors that take String arguments as well.
>
> I'm a bit undecided on dealing with TransformerException and
> SAXExceptions - should I wrap them in RuntimeExceptions as well or do
> we expect tests to gracefully deal with invalid XML input?
>

I haven't written / come across any tests where I would expect them to
handle this. IMHO, invalid XML has always been considered a problem in
the test environment, rather than something specifically tested for.
That said, might be worth defining a subclass of RuntimeException so
that client tests can do the following:

try {
   doSomething();
   fail("provided input wasn't valid xml");
catch (XMLUnitException expected) {
   // pass
}

> Cheers
>
>         Stefan
>
> --
> http://stefan.samaflost.de/
>

I'll check out the source and see if I'm suitably inspired to pitch in.

Cheers,

James

[1] http://sourceforge.net/mailarchive/message.php?msg_id=13656151

[Xmlunit-general] Under development again

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

Hi all,

just in case there still is anybody listening I thought I'd better
give you a heads up, now that I start breaking everybody's code 8-)

A few months ago I asked Tim and Jeff whether they'd be around to
accept a few patches and Jeff was kind enough to give me commit
access.

Back then my primary interest was - and still is - to get the .NET
version into shape, in particular I'd like to make it work with more
recent versions of NUnit and the .NET framework (as well as Mono).

For the time being I've spent more time on the Java codebase since
this is the one I was more familiar with.  I started fixing a few of
the open bugs and by now managed to make XMLUnit pass all its test
under JDK 1.5 and 1.6 as well.  In order to do that I've added to
SimpleXpathEngine a JAXP 1.3 implementation that gets used under the
covers if it is available.

My short term goal is to add XML Schema validation and XML namespace
support for XPath assertions, which should mean I'd have addressed
almost all open issues in the trackers.  Once done I'd like to do a
1.1 release of XMLUnit/Java - and start working on the .NET version
after that.  Any objections?

Also I'd like to move to subversion sooner rather than later.

Longer term I'd like to break up XMLUnit a bit more.  The XML diff
engine is usable standalone and I'd like to see it as a first class
citizen with the *Unit test framework classes just using them.

Speaking of *Unit, I want to add support for JUnit4 style assertions
(actually Java 1.4 style) and maybe TestNG on the Java side and look
at the stuff Peli has done for the MBUnit integration on the .NET
side.  Support for Team Test might be an option there as well.

Certain parts of XMLUnit won't see much love during that process, in
particular the classes that support working on good old HTML might
better be replaced by something like JTidy in the tests.

In general I want to keep stuff backwards compatible - those who know
my work on Ant know that I can get pretty paranoid when it comes to
BWC - but I'll be breaking things every once in a while.

If anybody thinks that the deprecated methods should not be removed
before the next release, please speak up now.

I started to refactor parts of the exception handling.  Any
ParserConfigurationException or TransformerConfigurationException now
gets wrapped in a RuntimeException - you cannot recover from that
anyway.  I'll probably try to remove IOException from all
methods/constructors that take String arguments as well.

I'm a bit undecided on dealing with TransformerException and
SAXExceptions - should I wrap them in RuntimeExceptions as well or do
we expect tests to gracefully deal with invalid XML input?

Cheers

        Stefan

-- 
http://stefan.samaflost.de/

[Xmlunit-general] XmlUnit.Net implementation

[Kurman K. <kka...@th...>]

Hi, 

We are trying to use XMLUnit.Net on our project however it is very 
difficult to see what are the differences in control and test inputs.
After looking at .NET implementation of the tool we realized that it is 
quite different from Java implementation. Is there any reason why Java 
version was not ported to .NET?


Regards,
------------------------------
Kurman Karabukaev
Application Developer
ThoughtWorks Inc.
(312) 282 0231

[Xmlunit-general] Help on how to ignore some nodes during comparison

[Abhin U. <ud...@gm...>]

Hi,
    I am relatively new to xmlunit, and need to compare two xml files got
from different sources.
    I have two xml files which look something like this :

<Customer-list>
         // Various customer nodes
         <Customer>
               <Attribute name=3D"Name">
                         <Value>John</Value>
               </Attribute>
         </Customer>
</Customer-list>

 <Customer-list>
         // Various customer nodes
         <Customer>
               <Attribute name=3D"Name">
                         <Value>John</Value>
               </Attribute>
                <Attribute name=3D"Age">
                         <Value>36</Value>
               </Attribute>
         </Customer>
</Customer-list>

I want the comparison of these two nodes to be accounted as similiar.
i.eThe Age node has to be ignored completely ( Even if the values of
age are
different in the two nodes, or absent in one of them ) during comparison.

Is there any easy way, without writing a recusrsive search and ignore
myself.

Thanks,
Abhin H

[Xmlunit-general] using XSD's for validation

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

Hi,

Seems to be the most popular subject on the mailing lists!

Are there any plans to support this, or would you be interested in
considering a patch for submission? I've not looked at the XMLUnit
source yet, but I did implement in-line something fairly similar to
this:

http://sourceforge.net/mailarchive/forum.php?thread_id=3D2081145&forum_id=
=3D9345

With my user hat on, I'd like this to be in core XMLUnit, rather than
having my own class wrap that functionality.

Regards,

James

Re: [Xmlunit-general] Active?

[Jeff M. <je...@mk...>]

What's the question?

On Mon, 2004-12-13 at 08:33 -0800, Martin Wegner wrote:
> Greeting.  Is this project still active?  I have some questions about
> getting XMLUNIT to work.
> 
> Thanks.
> 
> 
> --Marty
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 55 478 331
phone: 44 (0) 20 77 29 45 45
email: jef...@mk...

www.mkodo.com

73 Leonard St, London, EC2A 4QS. U.K

[Xmlunit-general] Active?

[Martin W. <mar...@ya...>]

Greeting.  Is this project still active?  I have some questions about
getting XMLUNIT to work.

Thanks.


--Marty

[Xmlunit-general] validation

[<gre...@fr...>]

Hi list,

I wanted to validate some generated xml documents, which I already diff 
with xmlUnit. I also wanted to avoid loading the dtd's over the network, 
so I tried sthg like the solution proposed here :

 http://sourceforge.net/mailarchive/forum.php?thread_id=1515032&forum_id=9345

I never managed to have my EntityResolver being actually used. (Tried 
debugging, break points never reached)

Did I do something wrong, or is there someone who has actually managed 
to do this? (through xmlunit - outside xmlunit, it works, I wrote a 
small and straightforward package that does just the validation)

I'll take any tips. If nobody has a solution, and/or someone show 
interest, I could publish my mini-package for validation, although I 
really suspect this already exists in 20 different flavours..

greg

[Xmlunit-general] validation

[<gre...@fr...>]

Hi list,

I wanted to validate some generated xml documents, which I already diff 
with xmlUnit. I also wanted to avoid loading the dtd's over the network, 
so I tried sthg like the solution proposed here :

 http://sourceforge.net/mailarchive/forum.php?thread_id=1515032&forum_id=9345

I never managed to have my EntityResolver being actually used. (Tried 
debugging, break points never reached)

Did I do something wrong, or is there someone who has actually managed 
to do this? (through xmlunit - outside xmlunit, it works, I wrote a 
small and straightforward package that does just the validation)

I'll take any tips. If nobody has a solution, and/or someone show 
interest, I could publish my mini-package for validation, although I 
really suspect this already exists in 20 different flavours..

greg

[Xmlunit-general] (no subject)

[John H. <ha...@eb...>]

confirm 307291