RE: Help wanted: A xslt transform for tests to HTML

> Just got in, won't have time to do anything useful before tomorrow 
> morning my time, but I ran Manos' stylesheet which displays fine in 
> Mozilla.
> 
> I'll work on it now and post it later on, possible tomorrow as I also 
> have to get ready for the W3C Cannes meetings.
> 
> I'll read mail again before taking the plane tomorrow, could you 
> formulate any isses you want me to take up with the DOM WG?

The contention that non-validing implementations are not required to provide
default attribute values and doctype nodes.  This could be broken down into
several subsets, those tests that require reading the external subset, those
that require processing the internal subset, etc.  You might review the
Mozilla Dom L1 Core test summary that I did last November
http://lists.w3.org/Archives/Public/www-dom-ts/2001Nov/0011.html

The getElementsByTagNameNS("*",...) interpretation.

Whether "no effect when defined to be null" takes precedence over the
NO_MODIFICATION_ALLOWED_ERR exception clause for setNodeValue.

> I can see 
> the following:
> 
> 1. We are about to have 400+ HTML tests submitted from NIST
> 2. We are about to have 150 HTML tests submitted from 
> Netscape (middle 
> of March)


> 3. We are working on a web-based harness for the ECMA tests (and it 
> looks as if we'll drop Junit at some point, given Bob's work)

Did you mean JUnit or JSUnit.  Dropping JUnit would be a bad thing since
using a standard testing framework makes it easier for the DOM tests to get
integrated into the standard build process of implementations.  Requiring a
custom testing framework hinders use of the tests.

Having a custom runner for browser-based testing is beneficial, however I'd
still like the tests to be runnable both with JSUnit and the custom browser
runner.

Received on Monday, 25 February 2002 18:07:21 UTC