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

On Thu, Aug 11, 2011 at 6:28 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
> 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.

While I think HTML/Web Applications 1.0 might be overboard when it
comes to spec length, I strongly feel that we should not be splitting
things up into lots of little specs of a few pages each.  DOM Core as
it stands is a reasonable length and covers a pretty logical grouping
of material: everything related to the DOM itself without dependence
on the host language.  I think it would be logical to add some more
things to it, even -- Anne and Ms2ger and I have discussed merging
Ms2ger's/my DOM Range spec into DOM Core (Range only, with the
HTML-specific Selection part removed).

We don't have to feel bound by the way things were divided up before.
Historically, we've had lots of little specs in some working groups
partly because we had lots of people putting in small amounts of time.
 These days we have more editors capable of handling larger specs, so
it's logical to merge things that were once separate.  As long as
there are no substantive issues people have with the contents of the
spec, I don't think it's productive at all to tell willing and capable
editors that they can't edit something or that they have to write it
in a more complicated and awkward fashion because some people have an
aesthetic preference for smaller specs or because that's the way we
used to do it.

It's true that procedurally, the more we add to a spec the harder it
will be to get it to REC.  I have not made any secret of the fact that
I view this part of the Process as a harmful anachronism at best, but
in any event, it shouldn't be prohibitive.  Given that we have to make
REC snapshots, the way it's realistically going to have to work is
we'll split off a version (say DOM 4 Core) and start stabilizing it,
while continuing new work in a new ED (say DOM 5 Core).  We can drop
features that aren't stable enough from the old draft when necessary
-- we don't have to drop them preemptively.  That's the whole idea of
"at-risk" features.

Also, a lot of the features we're talking about are actually very
stable.  I've written very extensive test cases for DOM Range, for
instance, and I can assure you that the large majority of requirements
in the Range portion (as opposed to Selection) have at least two
independent interoperable implementations, and often four.  I don't
think that merging Range in would have to significantly slow progress
on the REC track.  I imagine Traversal is also very stable.  Things
like a DOM mutation events replacement would obviously not be suitable
for a draft we want to get to REC anytime soon, but again, it can be
put in the next DOM Core instead of a separate small spec.

I also definitely think that DOM mutation events have to be in DOM
Core.  Things like Range and Traversal can reasonably be defined on
top of Core as separate specs, since Core has no real dependency on
them.  Mutation events, on the other hand, are intimately tied to some
of the basic features of DOM Core and it isn't reasonable to separate
them.

Received on Thursday, 11 August 2011 15:07:15 UTC