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

Re: Status check

From: Robert Clary <bclary@netscape.com>
Date: Thu, 23 May 2002 15:25:29 -0400
Message-ID: <3CED4229.5050102@netscape.com>
To: Dimitris Dimitriadis <dimitris@ontologicon.com>
CC: Rick Rivello <richard.rivello@nist.gov>, www-dom-ts@w3.org, edward@jsunit.net
Dimitris Dimitriadis wrote:
> Thanks
> Also, let me be more precise: differences insofar as compatibility with 
> the existing bulk of tests and their funcionality is concerned.
> Thanks
> /Dimitris

I think it will be best if I can work directly with someone who is more 
familiar with the actual architecture of the DOM TS. I can attempt to 
adapt several tests to see what over all modifications will be needed 
however I do not feel comfortable making design decisions regarding the 
DOM TS. I consider the design choices to require more time than making 
the actual modifications that will be needed.

Some changes I can identify now are:

1) it should not be necessary to patch jsUnit. The build will have to be 
modified to remove the patching.

2) the xslt transforms will needed to be modified to a limited extent I 
believe. Since only IE5+/Windows and Mozilla support auto-discovery of 
test function names, in order to allow the widest range of browsers to 
execute the tests, the test function names will need to be exposed via 
the exposeTestFunctionNames() function. There may be additional changes 
to support data document loading however this depends to a great extent 
upon the decisions made in #3 below.

3) design decisions will need to be made on how to load documents and 
what options will be available for choosing the method of loading 
documents, whether to cache documents for reuse, etc. This includes 
decisions on how to invoke the tests, what parameters to pass, etc.

As I envision one possibility, a configuration page would allow the 
tester to choose the document loading method to be used (IFRAME, MSXML, 
Adobe SVG plugin,...), then jsUnit would be invoked via a url which 
contained the test page to run, information regarding how to load data 
documents, etc.  I believe the most appropriate means of using the 
ability to pass information to test pages via urls requires a web server 
rather than file based urls however I would like guidance on whether 
this is appropriate.

4) the builder object will require modification to support the decisions 
made in #3.  I can propose designs for consideration and comment or I 
can work with someone to produce the designs.

Considering that my predilection is to favor non proprietary document 
loading strategies, it would be best if I had guidance. For example, I 
believe that Internet Explorer 5+ will fail all XML based tests where a 
test XML data document is loaded into an IFRAME and the IFRAME's 
document is used in the test. I believe this is reasonable and 
appropriate for pure browser tests. Testing documents loaded via MSXML 
or other ActiveX control or plugins is also appropriate however is a 
test of the control or plugin and is not a test of the browser per se.

I am sure this approach will be controversial and I do not want to 
attempt to make any such decisions on my own without guidance from the 
DOM TS group.

Received on Thursday, 23 May 2002 15:27:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:05 UTC