RE: [DOM TS Design: Test definitons]

Okay -- it's pretty crude, but this is what we have been up to.  I've
defined an external DTD, called methods.dtd.  Inside this dtd, I have
definitions for describing a particular test scenario (at this point,
it is crude, but allows us to illustrate the point).  We would of
course augment this test description with pointers to the spec, and
additional documentation for generating in-line comments for code, etc.
This file also contains a conditional include, which defines names for
each binding (methods for Java, functions or properties for ECMAScript).
I've come to realize that what we have is overkill -- we don't really
need a type definition for each call -- instead, we could simply have
a collection of allowable types.  At any rate, this approach relies on
using the idl name as the entity name and the particular binding as the
value of the entity.

I also have something called domtests.xml, which calls in methods.dtd,
and a discrete set of tests -- right now, it is nist/node.xml -- inside
node.xml, I have definitions for each test scenario -- this example uses
only the nodeType tests, but I think it can be extended to cover all
of our tests.  Under test scenario, I've defined the necessary steps,
using the appropriate idl entity def's, which will in turn substitute the
approriate bindings, to execute a particular test. This approach needs
some additional work -- in particular, support for if's and loops,
operating on a particular object, and simple assignments.

Using the supplied stylesheet, java.xsl, I'm able to generate a set of
node tests.  I'm currently using the xerces parser and xalan 2.  I've
supplied a simple Test driver, Test.java, that loads the xml file we
are operating on -- staff.xml (staff.dtd) and simply uses the reflection
api to get at all defined test methods, run them, and print out the results.
I've purposely kept this simple until we know the end approach -- at that
point, it can be polished to work with additional parsers, different input
files, and automatically comparing expected and actual results.  The idea
is that we can write additional stylesheets for ECMAScript, Perl, Python,
etc.

Comments / suggestions?

Mary Brady
NIST, Web Technologies
mbrady@nist.gov

-----Original Message-----
From: www-dom-ts-request@w3.org [mailto:www-dom-ts-request@w3.org]On
Behalf Of Dimitris Dimitriadis
Sent: Thursday, March 22, 2001 10:04 AM
To: 'Stanley Guan'; www-dom-ts@w3.org
Subject: [DOM TS Design: Test definitons]


As indicated in a previous mail, we have indeed thought about this. If would
be a great thing if we could describe the tests in a language-neutral way
and automatically generate tests for a particular language.

However, as we've ancountered some difficulties, I'd personally like to see
a thread on this mailing list to discuss this.

The objectives are:
1. Describe tests in IDL terms
2. Generate tests for particular languages
3. Point to relevant part of the specification

/Dimitris

-----Ursprungligt meddelande-----
Från: Stanley Guan [mailto:Stanley.Guan@oracle.com]
Skickat: den 21 mars 2001 19:03
Till: www-dom-ts@w3.org
Ämne: [Fwd: NodeList (Re: CSS::SAC)]


>In all respects, a conforming Perl DOM lite implementation, via an OMG
>IDL wrapper, should be a conforming DOM implementation.  Mostly it's a
>difference in presentation.

Has this point of view been taken into consideration?

Thx,

-Stanley