- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Thu, 11 Aug 2011 11:06:17 -0400
- To: Arthur Barstow <art.barstow@nokia.com>
- Cc: public-webapps <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Adrian Bateman <adrianba@microsoft.com>, Doug Schepers <schepers@w3.org>, Jacob Rossi <jrossi@microsoft.com>
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