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
>