W3C home > Mailing lists > Public > www-dom-ts@w3.org > June 2001

Re: [General] domconftest now a project at SourceForge

From: Mary Brady <mbrady@nist.gov>
Date: Thu, 28 Jun 2001 14:05:08 -0400
Message-ID: <009901c0fffc$dde90010$293b0681@HAPPY>
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
> 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
> seems fine), on the other hand, lacking time maybe we should leave this
> 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.
agree that links for the straightforward purposes could be automatically

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.

Received on Thursday, 28 June 2001 14:06:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:03 UTC