RE: [General] domconftest now a project at SourceForge

> [mb] During a previous interation of the xml-ized dom tests,
> we had metadata info with each test, so these are already
> defined on a per test basis.  It should be straightforward to
> transform them into the rdf tagset, and merge the metadata with
> the updated xml (according to Curt's schema) definitions.  So,
> I should look at subjects.rdf for this???

subjects.rdf (probably the last one as subjects.xml) should
give you standard URI's for a good subset of the spec.

However, it would be a manual process of searching for
an appropriate text string and then finding the nearby URI.
That could get very annoying if you have to do it often.
I was thinking it might be possible to build a stylesheet
that would transform this to HTML and to have a script
that would copy the URI to the clipboard when you clicked it.
That way you could find the appropriate section in the HTML,
click the URI and then paste into the test.

Might be good to see examples of what your current metadata looks like.

> [mb] Not sure I am following this conversation.  What do you 
> want to have
> automatically generated?  

Almost anything that we have written transform for.  The full
ANT build process for DOM Level 1 would do something like:

Download DOM.zip from the W3C site
Unzip DOM.zip
Unzip xml-sources.zip
Patch wd-dom.xml to add missing xmlns:xlink attribute
Apply dom-to-xsd.xsl to generate schema
Fixup _xmlns in schema
Apply dom-to-dtd.xsl to generate DTD (doesn't exist right now)
Apply extract.xsl to generate interface definitions
Apply subjects.xsl to generate RDF descriptions of potential test subjects
Apply test-to-java.xsl to all known tests to generate Java code
Compile all generated Java code
Build .jar file
Build documentation

The same process should also be repeatable for DOM Level 2, 3 and so on.  I got as far as "Apply dom-to-xsd.xsl" before running into the Xalan or Ant bug that I described.

> There have been two threads along 
> these lines.
> One was regarding automatically generating test purposes from 
> the spec,
> which, in my opinion, can only partially be done.  There are 
> a fair number
> of test cases that come from the spec, but are part of the 
> prose within a
> particular section -- these are typically the more 
> complicated test cases.
> I
> agree that links for the straightforward purposes could be 
> automatically
> generated.

The generated list isn't exhaustive and you can definitely
identify other passages by an XPointer syntax.  The generated
list just provides a list of systematically generated URI's
for the most obvious targets.

> The other thread was regarding pulling the tests together 
> into a particular
> test suite.  There are a couple of things that we need to 
> decide on here --
> if we suppose that we have a list of test purposes, with 
> links to xml-ized
> tests, and we know where the transformation resides, it should be
> straightforward to generate a test suite.  I haven't used 
> Ant, so I'm not
> sure that I could help with this approach -- but I would 
> think that this
> could be accomplished in any number of ways.  

Deciding whether a particular test is blessed to appear in a suite
is a editoral judgement.  However, to qualify for consideration, a
test should be schema/DTD valid, the generated code should
compile successfully, and the results of benchmark processors
against the test should be available.

Even if a test was decided to be a "bad" test, you should still
be able to run it.  It just wouldn't run as part of a specific suite.

> It's probably fairly
> important that we decide whether we want to support just the Junit
> framework for Java, or do we want something more generic in addition
> to the framework.  Can anyone think of any java implementations that
> will not run under the Junit framework?  If not, I'm happy 
> enough to go
> with it.  

In the current generated Java code, I've abstracted all the test framework dependency into the DOMTestFramework interface that is passed
as an argument to the runTest method.  The generated code
has no dependency on any JUnit classes, however the DOMTestFramework
methods bear a resemblence to methods in JUnit's TestCase.

To run within JUnit, you would need an standard adapter class that would
implement DOMTestFramework and call the runTest method of the
generated class.

A similar process would be needed for any other arbitrary
test framework.  The Batik project, for example, would want
to run on an internal Apache test framework.  They would
create their own adapter class, but they could use the same
.jar file as a JUnit based test.


> As far as ECMAScript goes, couldn't we get folks who have
> those implementations to propose a framework?  I can spend some time
> on it -- but probably not until next week.

Received on Thursday, 28 June 2001 15:06:13 UTC