- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Thu, 28 Jun 2001 14:32:38 -0600
- 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 >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