RE: [Bugtracking] Scope of domconftest

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

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:

http://www.w3.org/2001/DOMTS/Level-One/Test-Definition
http://www.w3.org/2001/DOMTS/Level-Two/Test-Definition
http://www.w3.org/2001/DOMTS/Level-Three/Test-Definition

(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

http://www.w3.org/2001/DOMTS/tests/... 


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

http://www.w3.org/2001/DOMTS/files/staff.xml

(I forgot to put a files directory in my CVS tree discussion earlier
today).

Received on Thursday, 28 June 2001 16:36:50 UTC