- From: Mary Brady <mbrady@nist.gov>
- Date: Thu, 28 Jun 2001 14:05:08 -0400
- To: "Dimitris Dimitriadis" <dimitris.dimitriadis@improve.se>, "'Arnold, Curt'" <Curt.Arnold@hyprotech.com>, <www-dom-ts@w3.org>
comments inlined ----- Original Message ----- From: "Dimitris Dimitriadis" <dimitris.dimitriadis@improve.se> To: "'Arnold, Curt'" <Curt.Arnold@hyprotech.com>; <www-dom-ts@w3.org> Sent: Thursday, June 28, 2001 1:34 PM Subject: SV: [General] domconftest now a project at SourceForge > >After the core tests work, > >we'll have to add metadata info -- but I > >think I can write a transform to put our > >original work into the rdf framework -- > >is this what we want to do? > > Not quite sure what you are starting from. I thought > the test matrix was almost a manual affair. > [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??? > >How do we envision the metadata info being used? Can > >we write a transform that will allow it to > >be displayed in a web browser, or will we > >have to transform off-line and make a html > >version available? > > Since building a test matrix would require crawling all the > available tests, I think generating it is part of the build > process. You could capture the entire matrix in RDF by > appending descriptions of the tests to the subjects.rdf file > and using a browser side transform. However that seems > overkill at this time and generating an HTML test matrix > as part of the build seems reasonable. > > [dd] If I remember correctly, some things we wanted to do with the metadata > was to categorize, build new versions of the DOM TS and easier maintenance > of test collections. > > I agree with Curt that we would like to have it generated (part of the build > seems fine), on the other hand, lacking time maybe we should leave this for > the next version. > > I did spend some time writing an Ant build file, but was running > into a problem with either Ant or Xalan using the wrong base for > resolving external entity references causing schema generation to fail. > [mb] Not sure I am following this conversation. What do you want to have automatically generated? 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 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. 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. 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. --Mary >
Received on Thursday, 28 June 2001 14:06:59 UTC