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