VB: [Action Items] Top priority (Revision period, ECMA transform, Harness, Packaging)

This was presumably meant to be sent to the list.

/Dimitris

-----Ursprungligt meddelande-----
Från: Arnold, Curt [mailto:Curt.Arnold@hyprotech.com]
Skickat: den 20 augusti 2001 21:41
Till: 'Dimitris Dimitriadis'
Ämne: RE: [Action Items] Top priority (Revision period, ECMA transform,
Harness, Packaging)




> -----Original Message-----
> From: Dimitris Dimitriadis [mailto:dimitris.dimitriadis@improve.se] 
> Sent: Monday, August 20, 2001 12:12 PM
> To: 'www-dom-ts@w3.org'
> Subject: [Action Items] Top priority (Revision period, ECMA 
> transform, Har ness, Packaging)
> 
> 
> Revision
> A mentioned earlier, we should need no more than a week to 10 
> days to agree on the quality and correctness of the tests.I 
> propose that requests to put individual tests in the issue 
> tracking project are put forward to this list first, in order 
> to save time if there is a very simple solution. [All]
> 
> ECMA transform
> We should be able to produce one fairly soon, as we have a 
> solid Java transform [ca/dd/?]

There is a test-to-ecmascript.xsl in the CVS right now that creates
Javascript that is obviously strongly reminsent of the Java generated from
test-to-java.xsl.

The major issue is the apparent lack of a method to synchronously load an
XML document in Netscape 6/Mozilla.  Much earlier (and more naïve) attempts
to run DOM tests asychronously have exhausted the
call stack crashed.  I've posted a query on the Netscape DOM newsgroups and
have some of my own ideas to address the problem, but have, for obvious
reasons, not spent any time on it yet.

I believe there are issues that we will have to get some resolution from the
DOM WG in regard to the ECMAScript binding.  Specifically, the null string
behavior that was originally mentioned in the
hasFeature thread on the www-dom earlier this summer.  This also affects
Entity.systemId, Entity.publicId, Notation.systemId, Notation.publicId and
an HTML related method that I can't remember off the
top of my head.  Basically, all these properties state that null should be
returned under certain circumstances.  MSXML, and I believe,
Netscape/Mozilla return a zero-length string which is consistent
with ECMAScript's string type not having null in its value space.

> Harness
> The DOM WG expressed the wish for the possibility to be able 
> to run the ECMA variants of the tests, presumably directly 
> from the DOM TS pages. This does raise the issue of making 
> available the test descriptions and the stylesheets only 
> (together with the DTD/Schema, if needed) in order to write 
> the harness. Also, however, this raises issues on letting 
> people write their own harnesses around the tests. [mb/all]

The major problem with running the suite (naively again) from a remote site
is the number of loads of the support files (staff.xml, staff.dtd).  If it
is possible to load the resource files once and
then provide clones in response to the load() calls, then the suite should
perform adequately.

> 
> Packaging
> Freek's first file used the suite.member convention, which 
> looks fine to me, so I propose that we continue using that, 
> as was originally proposed, unless anyone thinks otherwise. 

That is what is in the DTD and used in previous personal iterations.  I just
didn't have the chance to build one before crashing.

> 
> Remaining metadata issues (erroneously given as Low Priority 
> previosly) Is this final? Are we going to look into it some more?
> 

I think the inline metadata has been adequately resolved.

Received on Tuesday, 21 August 2001 07:25:20 UTC