- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Thu, 28 Jun 2001 13:02:05 -0600
- To: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
> [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