W3C home > Mailing lists > Public > www-dom-ts@w3.org > August 2001

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

From: Mary Brady <mbrady@nist.gov>
Date: Thu, 23 Aug 2001 12:58:17 -0400
Message-ID: <001801c12bf4$ce611cd0$293b0681@HAPPY>
To: "Curt Arnold" <carnold@houston.rr.com>, <www-dom-ts@w3.org>
I've just begun looking at the code, but I think that's pretty much what we
already have -- check out the attached .js file.  I'm not too concerned
marrying ECMAScript to HTML, as most of the solution appears to be
in ECMAScript -- file loads, etc -- just the user interface -- selecting
tests to run, invoking, and reporting are in HTML -- I am hopeful that this
portion may be replaced by JSUNIT.


----- Original Message -----
From: "Curt Arnold" <carnold@houston.rr.com>
To: <www-dom-ts@w3.org>
Sent: Thursday, August 23, 2001 12:40 PM
Subject: Re: [Action Items] Top priority (Revision period, ECMA transform,
Harness, Packaging)

> > [mb] I expect that the jsunit version is based on the initial NIST
> > ECMAScript
> > tests?  If so, I wouldn't start from here -- it has not been updated to
> > include
> > info we learned from doing the java tests -- in particular, info that we
> > learned
> > regarding whitespace, entity expansion, etc., and is probably slanted
> > towards
> > MSXML, since that's what we had available at the time.  In addition,
> > tests were dependant on either synchronous load capabilities, or data
> > islands.
> That one is actually a transliteration of the NIST Java tests running
> JsUnit.  In the domunit effort, I took the NIST Java tests, converted to
> JUnit and then transliterated to ECMAScript and JsUnit and Xerces-C and
> CppUnit.
> Apparent lack of synchronous load capabilities in Netscape/Mozilla does
> complicate the issue substantially since the existing test frameworks
> a test to be complete when control returns from the runTest() method
> of having the results available at some later time (or potentially never
> getting the results from a test).
> I've been thinking about the feasibility by loading a pool of XML
> on test framework load and satisifying the load() method in the tests from
> that pool.  If the pool became empty, you could put up an annoying alert()
> box (I haven't found a way to kill time other than that) while the
> previously initiated parse requests are completed.  You could put an event
> listener on the document and only remove the document from the pool if you
> saw an real mutation (instead of all the attempted mutations that should
> have been blocked by an exception check).  Implementations that support
> synchronous parsing, could avoid all that.
> > His work is based on some of the earlier schema work, and has to be
> updated
> > to
> > be consistent with the present schema files.  I'll spend some time today
> > trying to
> > get it to work on my end, and post the results.  I'm sure the user
> interface
> > will
> > need some work, but it's a logical starting point.
> Great.
> However, can't marry ECMAScript exclusively to HTML since we would also
> to test ECMAScript and SVG.

Received on Thursday, 23 August 2001 13:00:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:13 UTC