RE: Action item list and agenda for telephone conference

>6. Lack of visibility (at least from outside the DOM WG)
>
>I haven't seen the existing XSLT transform for
>Java and ECMAScript.  I assume they are against the NIST
>DTD and maybe against the NIST testing framework.
>

The proposed language (DTD), transformation (XSL), all of the 
NIST Node tests (node.xml) and the translated java code (node.java)
were posted on this mailing list on March 23  -- 
http://lists.w3.org/Archives/Public/www-dom-ts/2001Apr/0040.html --
the transformation has not changed significantly since then -- we have 
updated the test descriptions and added the ability to automatically generate 
javadoc style comments with all of the tests.  

I've attached the files again -- node.xml, generate.xsl, and node.java so you 
can see the generated code.  All 400+ of the NIST tests have been encoded 
in this format, and we can generate java code for all of them. We have done 
some work on an ECMAScript version, but need to get the issues related 
to loading an XML doc worked out -- we could use some input from the 
ECMAScript folks here  -- in particular, some ideas from folks who can deal 
with a variety of ECMAScript implementations. 

>Since I'm spending a good deal of personal time on this,
>it would be good to have some idea that I'm not replicating
>work that is already going on.  It would be very helpful
>if people could publicly state at least what they are
>thinking about working on or need for their continued
>progress.

Quite honestly, I expected comments against what we had, but I didn't 
expect that you would completely re-do it :-).  Unfortunately, I do see duplication 
as I watch you going through much of the same thought process we've already 
been through: 

        - try to represent the test logic 
        - add capabilities as you step through the tests and find you need more
        - declare variables, because some of the tests might actually need this 
          (we actually did this as well, but decided in the end that we could 
           make the transformation smart enough to do it for us...)
        - etc...

Don't misread this message -- I actually like the idea of using a schema due 
to the added error checking that is inherent in it.  I don't mind using dom-like 
names as element names -- we didn't do this in the beginning because NIST 
is involved in lots of testing efforts, and we were interested in creating a language 
that could be used for other efforts as well.    

I am concerned at the time it is taking to run down the schema path.  Until more 
tests are encoded and there is an available transformation, I don't think that we'll 
have a schema that we are confident in.  Let's also keep our eyes on the future -- 
this framework is supposed to be used to develop tests for the rest of DOM Level 2 
and DOM Level 3.  

I think that we would get to where we want to go much faster if we agreed on 
an approach, defined a list of what needs to be done, and then all pitched in 
to get it done.  

--Mary

Mary Brady
NIST, Web Technologies
mbrady@nist.gov