SV: [General] domconftest now a project at SourceForge

comments inlined

A general point, though: We may want to limit functionality since we will
primarily use the SourceForge facilities for issue tracking, not so much to
publish the TS. This means that it will be more important to keep track of
issues relative to test correctness, than to have it in a particular
directory.

/Dimitris

-----Ursprungligt meddelande-----
Från: Arnold, Curt [mailto:Curt.Arnold@hyprotech.com]
Skickat: den 28 juni 2001 18:04
Till: 'www-dom-ts@w3.org'
Ämne: RE: [General] domconftest now a project at SourceForge


I guess we should spend some time on what the CVS should look like since
it is impossible to undo changes without leaving a trace.

We could put all submissions into a submissions module with subprojects
for the contributors

submissions
   submissions/nist
      submissions/nist/dom1
   submissions/microsoft
   submissions/carnold
   ..

[dd] As stated above, we will not (I think) have submissions primarily done
through SF, but through the www-dom-ts-submission mailing list. We may want
to have replication, though, so that we need not check things in manually as
they arrive and need to be discussed).

The files in this module would be a verbatim copy of what was submitted
and would not be modified.

For the active project:

domconftest
     tests
     java
         org
            w3c
                dom
                    testing
     ecmascript
     adapters
        junit
     

The structure below tests would mimic the organization used by NIST in
their submission below the tests project.  For example,
domconftest/test/dom1/fundamental/attribute/attributeName.xml, etc.

domconftest/java/org/w3c/dom/testing would only contain the interface
and abstract class definitions.  Actual tests would be in the same
namespace but generated in the build/java/org/w3c/dom/testing.

domconftest would contain an ANT build file and the transforms.

domconftest/adapters could contain source for adapters, code that allows
domconftest.jar to run in a specific test harness like JUnit.

Probably need to get an official decision about w3c package names we can
use.  I've been temporarily using org.w3c.dom.testing.

[dd] Philippe? Should we keep it in line with the package names for the DOM
bindings?

Mary Brady wrote:
>Sure, I'll help -- I should have the rest of 
>the fundamental and extended tests ready 
>by tomorrow.  

If the described structure seems appropriate, then
it would be beneficial if you could import your tests
into the submissions/nist and domconftest/tests directories.

[dd] Definitely, if we decide to use it for all tests, even the well-tried
NIST ones (just trying to avoid unneccesary work :)

>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.

>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.

Received on Thursday, 28 June 2001 13:34:51 UTC