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
