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

Re: Status check

From: Robert Clary <bclary@netscape.com>
Date: Fri, 24 May 2002 10:59:37 -0400
Message-ID: <3CEE5559.2040300@netscape.com>
To: Dimitris Dimitriadis <dimitris@ontologicon.com>
CC: Curt Arnold <carnold@houston.rr.com>, www-dom-ts@w3.org
comments to both messages [bc] inline

Dimitris Dimitriadis wrote:
> 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.
> 

[bc] That's the plan. :-)

> 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.
> 

[bc] I don't envision a need for a 'rewrite' however some modifications 
will have to be made to support asynchronous document loading. In 
addition, I am considering the replacement of the 'all' pages containing 
copies of the individual tests with jsUnit test suites. The asynchronous 
document loading is designed to work per test page and I do not think 
that it will be easy to combine them into a single test document. The 
replacement of the 'all' test pages with test suites should be 
relatively painless however.

> /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.

[bc] I consider a per test page configuration to be problematic. This 
would require more work in customizing each individual test I believe. 
My approach has been to consider all of the tests as a whole. The choice 
of implementation and other parameters would be made for all tests to be 
executed in a single run. jsUnit would receive these choices and set 
variables that can be queried by the 'builder' object in the individual 
tests to determine how to load and process data documents.

>> 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.

[bc] agreed. The details will be handled inside the 'builder' object and 
it's load method.

>>

[bc] Representative tests I have been looking at include tests with:

a) single data document (the vast majority of tests)
b) two data documents (about a half dozen)
c) tests which require the use of the embed tag to host the Adobe SVG 
plugin.
d) the use of jsUnit test suites to combine individual test pages.

I am not certain of the user interface of the test selection and 
configuration page. It will consist of a form that should allow 
selection of test suites or individual tests and overall configuration 
choices for implementation (native, msxml3/msxml4, adobe plugin, etc) as 
well as others. The form's action will be a GET to jsUnit's 
testRunner.html passing the choices encoded in the url.

My plan is to create a straw man that supports the following 
implementations: native (browser's document), msxml3/4 active x 
controls, adobe's svg plugin and the following:

a test page for a single data document
a test page for two data documents
a test suite consisting of the two test pages
a test selection and configuration page

These should allow us to determine the viability of the approach and the 
scope of any modifications that will be required to the existing build 
and xsl transforms.

I plan to have this available for comment sometime this weekend.

/Bob
Received on Friday, 24 May 2002 11:02:08 GMT

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