Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On 09/07/2011 05:09 PM, Aryeh Gregor wrote: On Sun, Sep 4, 2011 at 9:12 AM, Arthur Barstowart.bars...@nokia.com wrote: Some members of the group consider the D3E spec as the highest priority of our DOM-related specs and they have put considerable resources into that spec. Doug and Jacob will continue to lead that spec effort, and as I understand it, a CR for D3E is imminent. I expect the group to help progress that spec. At the same time, others members have put substantial resources into DOM Core (and closely related functionality such as DOM Range). Naturally, they want to preserve that investment and I support that work continuing. The real question is not who's invested what, it's what browsers will implement. If we're moving toward a situation where IE will implement D3E and everyone else will implement DOM Core's idea of events, What is the real difference in D3E and DOM4's idea of events? Just some different syntax for initialization (new Event() ), which I see as an additional feature on top of D3E. Features in D3E are actively being implemented also in non-IE browsers. and both groups will claim to be implementing the standard, that's an absolutely terrible idea and we need to put a stop to it right now. If the only real reason for it is because different editors or employers have made investments in different bodies of spec text, instead of because browser implementers actually disagree on what they should implement, that's even worse. I would object in the strongest terms to progressing any standard to CR if it contains features that are specified differently in a different standard, if it looks plausible that different implementers will follow different versions. (I have not looked at the content of D3E or DOM Core, though, so I can't say specifically how bad the situation would be if this happened, nor which should be retired in favor of the other.) Atm the situation isn't bad, IMHO. DOM4 just adds something on top of D3E. -Olli
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On 9/9/11 6:27 AM, ext Olli Pettay wrote: On 09/07/2011 05:09 PM, Aryeh Gregor wrote: On Sun, Sep 4, 2011 at 9:12 AM, Arthur Barstowart.bars...@nokia.com wrote: Some members of the group consider the D3E spec as the highest priority of our DOM-related specs and they have put considerable resources into that spec. Doug and Jacob will continue to lead that spec effort, and as I understand it, a CR for D3E is imminent. I expect the group to help progress that spec. At the same time, others members have put substantial resources into DOM Core (and closely related functionality such as DOM Range). Naturally, they want to preserve that investment and I support that work continuing. The real question is not who's invested what, it's what browsers will implement. If we're moving toward a situation where IE will implement D3E and everyone else will implement DOM Core's idea of events, What is the real difference in D3E and DOM4's idea of events? Just some different syntax for initialization (new Event() ), which I see as an additional feature on top of D3E. Features in D3E are actively being implemented also in non-IE browsers. and both groups will claim to be implementing the standard, that's an absolutely terrible idea and we need to put a stop to it right now. If the only real reason for it is because different editors or employers have made investments in different bodies of spec text, instead of because browser implementers actually disagree on what they should implement, that's even worse. I would object in the strongest terms to progressing any standard to CR if it contains features that are specified differently in a different standard, if it looks plausible that different implementers will follow different versions. (I have not looked at the content of D3E or DOM Core, though, so I can't say specifically how bad the situation would be if this happened, nor which should be retired in favor of the other.) Atm the situation isn't bad, IMHO. DOM4 just adds something on top of D3E. The D3E and DOM Core (nka DOM4) compatibility question has been asked before. I believe some alignments on both sides were made last May (before DOM Core was last published in /TR/). If additional changes need to be made to make these specs compatible, the www-dom list should be used for related discussions, issues, etc. -ArtB
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Sun, Sep 4, 2011 at 9:12 AM, Arthur Barstow art.bars...@nokia.com wrote: Some members of the group consider the D3E spec as the highest priority of our DOM-related specs and they have put considerable resources into that spec. Doug and Jacob will continue to lead that spec effort, and as I understand it, a CR for D3E is imminent. I expect the group to help progress that spec. At the same time, others members have put substantial resources into DOM Core (and closely related functionality such as DOM Range). Naturally, they want to preserve that investment and I support that work continuing. The real question is not who's invested what, it's what browsers will implement. If we're moving toward a situation where IE will implement D3E and everyone else will implement DOM Core's idea of events, and both groups will claim to be implementing the standard, that's an absolutely terrible idea and we need to put a stop to it right now. If the only real reason for it is because different editors or employers have made investments in different bodies of spec text, instead of because browser implementers actually disagree on what they should implement, that's even worse. I would object in the strongest terms to progressing any standard to CR if it contains features that are specified differently in a different standard, if it looks plausible that different implementers will follow different versions. (I have not looked at the content of D3E or DOM Core, though, so I can't say specifically how bad the situation would be if this happened, nor which should be retired in favor of the other.)
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Mon, 5 Sep 2011, Tab Atkins Jr. wrote: On Sun, Sep 4, 2011 at 6:12 AM, Arthur Barstow art.bars...@nokia.com wrote: Some members of the group consider the D3E spec as the highest priority of our DOM-related specs and they have put considerable resources into that spec. Doug and Jacob will continue to lead that spec effort, and as I understand it, a CR for D3E is imminent. I expect the group to help progress that spec. At the same time, others members have put substantial resources into DOM Core (and closely related functionality such as DOM Range). Naturally, they want to preserve that investment and I support that work continuing. I would like to publicly register that I find the sentiment expressed in the above paragraphs (regarding the work editors have put into the spec) as deeply troubling. I must agree in the most strongest terms with Tab here. As editors we must be willing to throw away efforts when it becomes clear that they are not the best solution for the Web. Witness for example Web SQL Database, which I jettisoned as soon as it was clear that it did not enjoy broad support. Sunk cost is never a valid economic reason to persue a particular course (q.v. the sunk cost fallacy [1]). This applies equally well to technical development. The fact that we have a specification written or that we have personally invested in it must have no bearing whatsoever on our decisions regarding whether to continue. [1] http://en.wikipedia.org/wiki/Sunk_costs#Loss_aversion_and_the_sunk_cost_fallacy -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On 9/5/11 3:34 PM, ext Tab Atkins Jr. wrote: We should make these kinds of decisions *solely* on technical grounds. Well surely making decisions on technical grounds is important. However, it seems a bit simplistic to consider it the only factor. (I seem to recall some previous decisions were based, for example, on existing implementations and deployments.) -AB
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
Hi All,
Thanks for the comments and discussion! I finally reviewed all of the
responses and here are my thoughts on moving forward ...
Some members of the group consider the D3E spec as the highest priority
of our DOM-related specs and they have put considerable resources into
that spec. Doug and Jacob will continue to lead that spec effort, and as
I understand it, a CR for D3E is imminent. I expect the group to help
progress that spec.
At the same time, others members have put substantial resources into DOM
Core (and closely related functionality such as DOM Range). Naturally,
they want to preserve that investment and I support that work
continuing. Although Aryeh's DOM Range spec was recently added to DOM
Core, the totality is still relatively small, at least when compared to
some other specs such as HTML5, SVG1, CSS2.
To help address feature creep for DOM Core, the Editors will notify
the list before adding any significant features to the spec.
Aryeh will become an Editor of DOM Core. Others that make substantial
contributions will also be considered as additional Editors (provided
they meet the type of requirements listed below). Adrian mentioned
Microsoft may be willing to provide editor resources for DOM and their
participation in DOM Core would of course be welcome.
Re the scope of DOM Core, I agree the spec lacks clear text regarding
its scope. Inputs for scope, as well as the spec's requirements, should
be submitted to the list.
Re the degree of done-ness of the various parts of DOM Core, I agree
this can create various issues. To help address this issue, it may be
useful for specific sections to include descriptive text about that
section's implementation and deployment status.
The CfC to publish a new WD of DOM Core was blocked by this RfC. I will
proceed with a request to publish a new WD of DOM Core in TR/. The name
DOM Core will be used for the upcoming WD. If anyone wants to propose a
name change, please start a *new* thread.
-Regards, ArtB
On 8/11/11 6:28 AM, ext 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.
-ArtB
On 8/4/11 2:24 PM, ext Adrian Bateman wrote:
On Wednesday, August 03, 2011 7:12 AM, Arthur Barstow wrote:
Anne would like to publish a new WD of DOM Core and this is a Call for
Consensus (CfC) to do so:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
Agreeing with this proposal: a) indicates support for publishing a new
WD; and b) does not necessarily indicate support for the contents of
the WD.
If you have any comments or concerns about this proposal, please send
them topublic-weba...@w3.org by August 10 at the latest.
Positive response is preferred and encouraged and silence will be
considered as agreement with the proposal.
Microsoft has some concerns about this document:
1. We have received feedback from both customers and teams at
Microsoft that
the name DOM Core is causing confusion with the previous versions of
DOM Core.
We request that the specification be named DOM Level 4 Core. The
original Web
DOM Core name
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Wed, Aug 31, 2011 at 8:25 AM, Anne van Kesteren ann...@opera.com wrote: I think defining all of these in one specification is fine. Currently the specification is only 37 pages when printed. That will certainly grow once we add ranges, examples, and more introductory text, but will also still be well below the larger specifications. (Jonas' concern is already addressed in the specification with notes that reference the other relevant places in case a feature (so far only some constructor methods on Document) is defined across sections.) Is this explicitly mentioned in the spec? Otherwise how will anyone be able to take advantage of this fact? / Jonas
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Wed, 31 Aug 2011 18:52:34 +0200, Jonas Sicking jo...@sicking.cc wrote: Is this explicitly mentioned in the spec? Otherwise how will anyone be able to take advantage of this fact? I guess we could explicitly mention it somewhere. On the other hand, everything has references and back-references and so far it seems to work fine for implementors (e.g. the new Event() feature is being picked up by implementors and so far the only question I got about it was about Web IDL dictionaries). Overall though I think it is somewhat distracting to put a 40 page specification in contrast with a 1000 page specification. This specification is very small and you can easily read/scan/search it through. -- Anne van Kesteren http://annevankesteren.nl/
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
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
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.bars...@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.
