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

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

From: Curt Arnold <carnold@houston.rr.com>
Date: Thu, 23 Aug 2001 11:40:26 -0500
Message-ID: <003c01c12bf2$50a0f3d0$a800a8c0@CurtMicron>
To: <www-dom-ts@w3.org>
> [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, those
> tests were dependant on either synchronous load capabilities, or data
> islands.

That one is actually a transliteration of the NIST Java tests running under
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 expect
a test to be complete when control returns from the runTest() method instead
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 documents
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 like
to test ECMAScript and SVG.
Received on Thursday, 23 August 2001 12:40:34 UTC

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