Re: DOM Test Suite task force

Robert Clary wrote:
>> It might be better to organize the components by sub-spec (Core, HTML, 
>> Events, LS, XPath) than by level.  The Level 1 owner isn't going to 
>> have much to do.
>>
> 
> The question is would
> 
> DOM Level 1
> DOM Level 2 Core
> DOM Level 2 HTML
> ....
> 
> be acceptable or would this create too many components?

I don't have a problem with that.

> The process to date has been for myself and others to raise points, 
> provide demonstrations of ideas, and solicit feedback. However you make 
> the final decisions as to the exact changes to the ECMAScript binding 
> and commit them to CVS without any discussion or approval of what those 
> specific changes will be.

Committing stuff to the CVS (on a branch if appropriate) in my opinion 
is a precondition for discussion and collaboration, not an attempt to 
preempt discussion.  It is in no way final since there is more than one 
committer and any ill-considered change could readily be reversed if 
there were complaints.

In this particular instance, the prototype was branched (apparently 
unintentionally) from the CVS sometime before July 2002, it would have 
been error prone to reconcile your prototype with the current CVS. 
Instead I attempted to incorporate the novel concepts from your 
prototype and the followup discussion into modifications of the current 
CVS to provide a path forward to which all could contribute.

If there had been any complaints, the 3 files that were changed easily 
could have been rolled back or split off into a branch.

It is counterproductive to do substantial work off-CVS.  It was 
unavoidable during the development of X-Hive's submission of Load/Save 
tests since it was based on a non-public draft, but knowing there was 
work going on but not being able to see it would strongly discourage 
anyone else from building LS tests for contribution.  If the test suite 
development had been done on CVS, other interested parties could be able 
to contribute since they would know there contributions did not 
duplicate X-Hive's efforts.  It also made it very difficult for me to 
modify the transforms to address problems with tests to which I did not 
have access.

> Under no circumstances would I feel that it is ok to check in a change 
> to CVS if there has been disagreement with either the Component owner, 
> the DOM TS chair or the DOM WG.

In regards to controversial tests, the following example might be 
helpful.  A couple of years ago David Brownell raised an issue 
(http://lists.w3.org/Archives/Public/www-dom-ts/2001Nov/0025.html) where 
Crimson alone implemented a particular reasonable interpretation of a 
passage of a DOM spec and every other parser known to man implemented a 
behavior that seemed contrary to the spec.  A well-known WG member said 
in a communication that I can't find something like "it kind of says 
that but it really means..." and referred to non-public WG communication 
to support his interpretation.

A definitive way to have resolved the conflict would have been to put 
one test for each of the behaviors into the CVS and petition the WG to 
explicitly reject one or the other.  If we attempted to avoid 
controversy, neither test would have added to the CVS and there would be 
nothing to compel resolution to this issue.

As long as a test is schema-valid, is consistent with a somewhat 
reasonable reading of the spec and doesn't have IP issues, the TS task 
force should not suppress a controversial test but should add the test 
to the CVS, survey the usual implementations and petition the WG to 
accept or reject the test.

I know Dimitris spent a huge amount of time with the QA team and maybe 
he can elaborate.  I think it is a good thing for the TS force to seek 
out potential controversy, crystalize it into potentially inconsistent 
test cases, survey the implementations and petition the WG for 
resolution and not to suppress controversy or preempt the WG's judicial 
role.

In regard to framework issues, there may be efforts like the enhancement 
of the ECMAScript harness that may extend for a substantial period of 
time.  I'd prefer to avoid it, but these types of efforts could be 
isolated in development branches in the CVS and only integrated to the 
stable branch when everybody is happy.  Totally locking down the CVS 
would encourage development to occur elsewhere, either in isolation or 
on some non-W3C CVS server.

Received on Friday, 18 April 2003 02:09:38 UTC