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

RE: [Bugtracking] Scope of domconftest

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Thu, 28 Jun 2001 14:32:38 -0600
Message-ID: <70E215722F6AD511820A000103D141D40AA3FF@thor.aeathtl.com>
To: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
Dimitris Dimitriadis wrote:

> I beleive we can start checking in the transforms and 
> schemata? (please note
> the correct use of the plural form of the greek word schema; 
> you may want to
> check out a thread rollling right now on xml-dev on 
> schemas/schemata which
> is very amusing).

Fortunately, it is not necessary to check in either schemas or
schemata since these are generated from the appropriate DOM
spec and the dom-to-xsd.xsl transform.

I think Tim Bray or some other illustrious personality tried
to squelch the schemas/schemata  thread early on, but to no avail.

> Basically, I think that a test should be committed to 
> the CVS as soon as it 
> passes the initial sanity check.  Committing a test to the 
> CVS doesn't imply endorsement that the
> test is a "good" test just that it doesn't break the build
> and people can run it to make value judgements.
> [dd] True. On the other hand, the existence of a test in a 
> browsable CVS may
> entail the risk of people looking at the wrong code and using 
> it before it
> is ready.

I agree with Fred, the expectation of a CVS download is the
code will build, but may contain stuff not ready for primetime.

If we are going to be able to effectively judge a test, then
we have to be able to run it.  Having every submitted test 
in the CVS and in the development builds is a necessity.
However, we could tweak the build so that only approved tests
go in the release builds.

> [dd] Currently yes, but given Philippe's latest mail not necessarily.
> > I think we should spend as little time as possible on this 
> > matter to start
> > working. I realize we need to decide on where development 
> > will take place,
> > but I also point out that SF was primarily thought of as a 
> > bug tracking
> > system. Mwe should spend some postings on this topic to reach 
> > a conclusion?

Philippe Le Hegaret wrote:
>We'll give as many access as necessary on the public CVS server [1].
>write access uses ssh, so I'll need the ssh public keys of the

Great.  Forgot all that I said about using the SourceForge CVS then.
However, the discussion on the structure under our project root
is still valid.

I haven't manually generated an SSH key before and don't have SSH
at work.  Any pointers?  If not, I give it my best shot when
I get home.

>Regarding the branch, I propose /2001/DOMTS to start with but I'm open
>to other proposals. Unfortunately, /DOM is an error on the public
>CVS server, so we can't reuse /DOM/Test.

There are a couple of identifiers it would be nice to get nailed down:

1. Namespaces for test definition:

I've been building these by appending #test-definition to the full URL
for the spec.  It will probably get sloppy for DOM Level 2 and beyond in that you don't want different namespaces for each subset (Events, Range/Traversal).

Could use:


(I still haven't comprehended how the trailing # does helps)

2. Java package names for tests

org.w3c.DOMTS ?

I don't think package names can contain numerics like 2001.

3. target URI's for tests


4. URI's for XML test files (like staff.xml)


(I forgot to put a files directory in my CVS tree discussion earlier
Received on Thursday, 28 June 2001 16:36:50 UTC

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