W3C home > Mailing lists > Public > www-dom-ts@w3.org > May 2002

Re: Status check

From: Dimitris Dimitriadis <dimitris@ontologicon.com>
Date: Fri, 24 May 2002 14:56:46 +0200
Cc: <www-dom-ts@w3.org>
To: "Curt Arnold" <carnold@houston.rr.com>
Message-Id: <B423CA79-6F15-11D6-A541-000393556882@ontologicon.com>
I'm all for a solution like that. In this way, we ensure that each 
implementation is tested on its own merits, which has been discussed 
earlier.

On the other hand, we'd need to steer clear of having to rewrite too 
much of the existing test chain (the stylesheets and build.xml, 
basically) and try to make the latest version of JsUnit as compatible as 
possible with what we've done so far.

/Dimitris

On Friday, May 24, 2002, at 07:39 AM, Curt Arnold wrote:

> Robert Clary wrote:
>> Ok. I will put together an example and post it so we can use it as a
>> straw man for discussion.
>
> My first inclination is to allow a JSUnit test page to be able to 
> provide a
> configuration page in a frame.  Something like:
>
> 1) Select the test from the browse button
> 2) The contents of the configuration page appears in a frame below the 
> test
> selection.  The page would allow you to select implementation and
> configuration (validating/non-validating, preserve entities/expand 
> entities,
> etc).  The configuration page for the test would either be implied from 
> the
> filename or might be determined by loading the test and evaluating a
> function.
> 3) When the test is run, a JSUnit method can be used to obtain the
> configuration document.
>
> Whether that is possible cross browser, I don't know.
>
> The boilerplate DOM TS code should hide all the gore from the DOM test
> itself.  The tests should be oblivious to the details of implementation
> selection.
>
>
>
>
Received on Friday, 24 May 2002 08:56:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:58:46 GMT