W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Ms2ger <ms2ger@gmail.com>
Date: Thu, 11 Aug 2011 13:47:07 +0200
Message-ID: <4E43C13B.4010706@gmail.com>
To: public-webapps <public-webapps@w3.org>
CC: Ian Hickson <ian@hixie.ch>, Aryeh Gregor <ayg@aryeh.name>
Hi Art,

(CCing some people you apparently forget to CC, but who might have an 
opinion on this matter, and a stake in the outcome of the discussion.)

On 08/11/2011 12:28 PM, 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.

I believe you missed "time and willingness to spend that time on editing 
the specification, both on the side of the editor and possibly their 
manager".

> 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.

Firstly, I find the description of the current DOM Core specification as 
a "kitchen-sink approach" rather exaggerated. On Letter paper, it 
currently covers between 40 and 50 pages, of which

* 2 pages on exceptions
* 5 pages on events
* 24 pages on nodes (the core of DOM Core, if you will)
* 6 pages on traversal
* 5 pages on various collection and list interfaces needed by the above.

As you can see, DOM Core is still primarily about nodes, and the 
enlargement caused by importing events and traversal is rather limited.

Secondly, these are all technologies that still lacked a specification 
in the algorithmic style we have come to expect from modern 
specifications. One could publish some of these chapters separately, and 
make them seem somewhat more worth of splitting, by doubling the 
boilerplate and hard-to-follow cross-specification references. Indeed, 
separate DOM Core and DOM Events specifications would be mutually 
dependent, and thus one would not be able to progress faster along the 
Recommendation track than the other.

Thirdly, these old-style specifications, by virtue of being split in 
chunks that only described one or two interfaces each (except for 
Traversal-Range, which combines two rather unrelated specifications into 
one document), tended to leave interactions between their technologies 
under-defined—perhaps each set of editors hoping the others would do 
that, and not considering themselves responsible for what are, indeed, 
some of the more difficult to author parts of the specification. This 
could be solved by either having both specifications be edited by the 
same people—which would introduce the overhead of having to decide, for 
every edit to a specification, which document the WG would like that 
edit to happen to—, or edited by different people who have to work 
together closely to ensure all feedback is addressed in one document or 
the other—this, too, causes obvious overhead, and a higher likelihood 
that feedback gets lost.

Fourthly, whatever the charter says about "ADMN", I will strongly object 
to the publication of any document trying to specify any kind of DOM 
Mutation handlers outside of the specification that defines DOM 
mutations, which, I assume, will remain DOM Core for the foreseeable 
future. Not because I like them so much that I want control over them, 
but because not having them specified along with the actual mutations is 
very likely to cause the behaviour in edge cases to under-defined (as we 
have seen before), or, at best, will need significant cooperation from 
DOM Core in order to define this clearly, and even in this case, I 
expect the set-up to be rather brittle.

Furthermore, if anyone wishes to step forward to help editing a 
Web-relevant specification, I would suggest they have a look at the 
"Specification TODO" page [1], which lists a number of technologies 
where their help is much more urgently needed. If they rather work on 
what is currently in DOM Core, however, I sure we can figure something 
out to make that possible.

To answer your questions above: you seem to have forgotten my preferred 
approach, to define the mark-up-language-, style-, and 
network-independent parts of the DOM (the core parts, I would suggest), 
which happen to be rather tightly coupled, in the DOM Core 
specification. As I've mentioned earlier, this reduces unnecessary 
overhead and increases the time editors can spend on technical, rather 
than procedural, matters. That can only be good for the Web, right? As 
for my availability and willingness to edit the specification; these are 
lessened each time I have to spend time on procedural and editorial 
matters, but I'm still willing to continue editing DOM Core.

Thank you for your thoughtful message
Ms2ger

[1] http://wiki.whatwg.org/wiki/Specifications_TODO
Received on Thursday, 11 August 2011 11:47:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT