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

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
about
marrying ECMAScript to HTML, as most of the solution appears to be
in ECMAScript -- file loads, etc -- just the user interface -- selecting
which
tests to run, invoking, and reporting are in HTML -- I am hopeful that this
portion may be replaced by JSUNIT.

--Mary

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