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

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

From: Jason Brittsan <jasonbri@microsoft.com>
Date: Wed, 29 Aug 2001 23:41:32 -0700
Message-ID: <D5C70EA9DF70694391969A1494875A120284060E@red-msg-05.redmond.corp.microsoft.com>
To: "Curt Arnold" <carnold@houston.rr.com>
Cc: <www-dom-ts@w3.org>
I've reviewed many of the ECMAScript files you mentioned... I don't see
any glaring problems that would prevent them from running in any
environment, but it's very difficult to be sure without running each
I'm not aware of any tools that check ECMAScript syntax outside of the
browser, but if I come across one, I'll inform the list.

	-----Original Message----- 
	From: Curt Arnold 
	Sent: Wed 8/22/2001 1:58 PM 
	To: Jason Brittsan 
	Cc: www-dom-ts@w3.org 
	Subject: Re: [Action Items] Top priority (Revision period, ECMA
transform, Harness, Packaging)

	I have been primarily trying to get the tests fixed and haven't
	spending any time on the ECMAScript stuff recently. 

	Probably the first thing to do is to get commit access to the
	server.  If you do not already have a public key on file with
the W3C, 
	generate one and send it to Dimitris so he can have you added to
	project.  Fred Drake recommended the SSH and CVS set up HOW-TO
at the Python 
	site http://python.sourceforge.net/winssh.txt, the little tidbit
	ssh-keygen failing unless -f is specified was definitely a piece
	information that I wish I had known. 


	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
	there should be a jsunit directory which contains JScript based

	Download Jsunit from http://www.jsunit.net and expand it into 

	There should be a file like DOMTestCaseConfig.js in the
	directory that will need to be edited to provide your base
directory and the 
	parser under test. 

	Then load /domunit/jsunit/jsunit/testRunner.html in IE, hit the
	button and file a test file in /domunit/jsunit.  Hopefully you
should now be 
	running tests. 

	We will probably diverge substantially from that, but that it at
least where 
	I'm starting from. 


	If you have (or want to setup) the build environment, build the 
	"dom1-core-ecmascript" target to generate a directory of .js
files (I think 
	it is build/ecmascript/level1/core).  I haven't done any
verification of the 
	code and am not an ECMAScript expert.  Could you examine the
files to notice 
	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
	could JScript.NET's command line compiler. 

	I've placed a snapshot of the currently generated ECMAScript at

	The tests (like the Java implementation) have two parts, the
	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 it 
	required hasFeature("HTML","") to be true and it was running on
just an XML 
	parser), then it would throw an exception in the constructor and
not be 
	reported as either a pass or a failure. 
Received on Thursday, 30 August 2001 02:42:08 UTC

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