- From: Curt Arnold <carnold@houston.rr.com>
- Date: Sun, 12 Aug 2001 22:47:23 -0500
- To: <www-dom-ts@w3.org>
- Message-ID: <002801c123aa$a96e11a0$a800a8c0@CurtMicron>
There are a few issues that would be beneficial to resolve (at least provisionally) before NIST does the initial load of tests. I propose that we do an Apache style vote on each of the issues. The possible votes are: +1: For the proposal, preferred alternative +0: Would tolerate the proposal, no strong feelings or less preferred alternative -0: Would prefer some other solution, but willing to go along. -1: Veto, serious reservations For a proposal to be accepted, there has to be some +1 and no -1's. ---------------- There needs to be some mechanism to distinguish test cases from test resources (like staff.xml in the NIST tests) from the test definitions. The alternatives in place or discussed are: a) parallel directory tree for resource files. For example, files/level1/core/staff.xml. Tests also use .xml extension. b) child directory for resource files. For example, tests/level1/core/files/staff.xml. Tests also use .xml extension. c) tests and resources in same directory, tests use .domtest extension, all other files (except .bak) are resource files. d) tests and resources in same directory, tests use .tst extension, all other files (except .bak) are resource files. e) Resource files are explicitly excluded by individual file name in build.xml Discussion: a is the approach in the current build.xml, but there is not a significant cost to change. Option d has a moderate chance of conflicting with file extensions of other testing software. c and d has the advantage of keeping the resource files in the same directory which would consistent with the use of relative URL's. =================== My votes (copy this section, replace with your votes, add any comments and reply to the list) a) +0 b) +0 c) +1 d) +0 e) -1
Received on Sunday, 12 August 2001 23:47:24 UTC