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 11:12:42 -0400
Message-ID: <00be01c12be6$0e12cc70$293b0681@HAPPY>
To: "Curt Arnold" <carnold@houston.rr.com>, "Jason Brittsan" <jasonbri@microsoft.com>
Cc: <www-dom-ts@w3.org>

----- Original Message -----
From: "Curt Arnold" <carnold@houston.rr.com>
To: "Jason Brittsan" <jasonbri@microsoft.com>
Cc: <www-dom-ts@w3.org>
Sent: Wednesday, August 22, 2001 4:58 PM
Subject: Re: [Action Items] Top priority (Revision period, ECMA transform,
Harness, Packaging)

> The second thing is to snag the inital domunit release which contained my
> initial take on the NIST test suite for ECMAScript.
> http://prdownloads.sourceforge.net/xmlconf/DOMUNIT.zip.  In that download,
> there should be a jsunit directory which contains JScript based tests.
> Download Jsunit from http://www.jsunit.net and expand it into
> domunit/jsunit/jsunit
> There should be a file like DOMTestCaseConfig.js in the /domunit/jsunit
> directory that will need to be edited to provide your base directory and
> parser under test.
> Then load /domunit/jsunit/jsunit/testRunner.html in IE, hit the browse
> button and file a test file in /domunit/jsunit.  Hopefully you should now
> running tests.
> We will probably diverge substantially from that, but that it at least
> I'm starting from.
> -------

[mb] I expect that the jsunit version is based on the initial NIST
tests?  If so, I wouldn't start from here -- it has not been updated to
info we learned from doing the java tests -- in particular, info that we
regarding whitespace, entity expansion, etc., and is probably slanted
MSXML, since that's what we had available at the time.  In addition, those
tests were dependant on either synchronous load capabilities, or data

In the last month, I've had one of my project members working on a html
He has put together a solution based on the current xml version of the tests
and has
figured out a way to get at least some of the tests working in both Mozilla
and IE -- there are issues with the entity, notation, and some namespace
in Mozilla, but other than that, things seem to work on the surface.

His work is based on some of the earlier schema work, and has to be updated
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
need some work, but it's a logical starting point.


> If you have (or want to setup) the build environment, build the
> "dom1-core-ecmascript" target to generate a directory of .js files (I
> it is build/ecmascript/level1/core).  I haven't done any verification of
> code and am not an ECMAScript expert.  Could you examine the files to
> any significant structural problems such as using language features that
> would not be available on all targets.  Is there any tool we could use to
> check the generated syntax before trying to run the tests, for example,
> could JScript.NET's command line compiler.
> I've placed a snapshot of the currently generated ECMAScript at
> houston.rr.com/curta/ecmascript.ZIP
> The tests (like the Java implementation) have two parts, the constructor,
> which determines if the test is compatible with the capabilities of the
> parser under test, and the test itself.  If a test was incompatible (say
> required hasFeature("HTML","") to be true and it was running on just an
> parser), then it would throw an exception in the constructor and not be
> reported as either a pass or a failure.
Received on Thursday, 23 August 2001 11:18:23 UTC

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