RE: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

On Thursday, August 11, 2011 3:29 AM, Arthur Barstow wrote:
> [ Topic changed to how to organize the group's DOM specs ... ]
> 
> Hi Adrian, Anne, Doug, Jacob, All,
> 
> The WG is chartered to do maintenance on the DOM specs so a question for
> us is how to organize the DOM specs, in particular, whether Anne's DOM
> spec should be constrained (or not) to some set of features e.g. the
> feature set in the DOM L3 Core spec.
> 
> There are advantages to the monolithic/kitchen-sink approach and, as we
> have seen with other large specification efforts, there aredisadvantages
> too. In general, I prefer smaller specs with a tight{er,ish} scope and I
> think there should be compelling reasons to take the monolithic
> approach, especially if there is a single editor. Regardless of the
> approach, the minimal editor(s) requirements are: previous credible
> experience, technical competence in the area, demonstrated ability to
> seek consensus with all of the participants and willingness to comply
> with the W3C's procedures for publishing documents.
> 
> In the case of AvK's DOM spec, there has been some progressive feature
> creep. For instance, the 31-May-2011 WD included a new chapter on Events
> (with some overlap with D3 Events). The 2-Aug-2011 ED proposed for
> publication includes a new chapter on Traversal. Additionally, the ED
> still includes a stub section for mutation events which is listed as a
> separate deliverable in group's charter ("Asynchronous DOM Mutation
> Notification (ADMN)").
> 
> Before we publish a new WD of Anne's DOM spec, I would like comments on
> how the DOM specs should be organized. In particular: a) whether you
> prefer the status quo (currently that is DOM Core plus D3E) or if you
> want various additional features of DOM e.g. Traversal, Mutation Events,
> etc. to be specified in separate specs; and b) why. Additionally, if you
> prefer features be spec'ed separately, please indicate your willingness
> and availability to contribute as an editor vis-à-vis the editor
> requirements above.

At Microsoft, we also prefer smaller more specific specifications for all
the same reasons that it makes sense to engineer software in smaller, more
modular parts.

* It is easier to implement and test smaller modules. Developers find it
easier to focus on one thing and it is easier for testers to do a thorough
job of preparing a test suite.

* While it is a little harder to make well-defined interfaces between
modules/specs, doing so is part of the engineering process that ensures a
good design.

* It's much easier to measure "done" when dealing with a smaller spec.
Moving the specification through the stabilisation process, getting complete
implementations, and achieving interoperability is easier when people are
focused on the same set of features. A larger, more monolithic spec always
leads to discussions about which parts are stable or unstable, which are
implemented and how well.

I think it's healthy to debate what should in or out of scope for a
particular document. Ideally this should be based on a set of requirements
or goals for the features. For example, it might be a goal to document the
profile of the DOM that is actually interoperable and in use on the Web
today. It might be a goal to add new features to this DOM that reduces the
amount of code necessary to perform a set of common tasks. It might be a
goal to add capabilities that improve performance of certain scenarios
popular in script libraries.

Microsoft is prepared to contribute more editing resources to the DOM
space once we establish the scope and structure of the future work.
Jacob has been assisting Doug with DOM L3 Events and moving this forward
is our highest priority here.

Cheers,

Adrian.

Received on Tuesday, 16 August 2011 22:53:03 UTC