Re: Status check

I'll be happy to help as far as I can.  I wrote the initial
document loading schemes for DOM, which I think
were mimicked in the DOM TS.  As far as mod's to the
transformations go, that's easy enough -- I'll defer to
Curt, who authored them.  If Curt doesn't have the
time, then I'll be willing to change them appropriately.
Just start the discussions, and let us know what you
need.  I'll try to put together an overview of the ways
we have loaded the tests in the past, and what our
current needs are, and post to the list.

--Mary

----- Original Message -----
From: "Robert Clary" <bclary@netscape.com>
To: "Dimitris Dimitriadis" <dimitris@ontologicon.com>
Cc: "Rick Rivello" <richard.rivello@nist.gov>; <www-dom-ts@w3.org>;
<edward@jsunit.net>
Sent: Thursday, May 23, 2002 12:25 PM
Subject: Re: Status check


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

Received on Thursday, 23 May 2002 15:59:24 UTC