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: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Fri, Aug 26, 2011 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote: The point is that if it's just a chapter in a larger spec, how do I know that there isn't other important information in the larger spec that I have to read in order to get a understanding of the full feature. The same applies if it's a standalone spec. Microdata is an example of a spec with so many dependencies on HTML5 that having it in its own spec is kind of silly: http://dev.w3.org/html5/md/Overview.html#dependencies A lot of features just aren't orthogonal. DOM mutation events are a great example of something that's tightly coupled to DOM operations, such that everything DOM-related needs to account for them, and it makes little sense to have them in a separate spec from DOM Core. Things like Traversal and Range could be in separate specs, but they're related enough and short enough that having them in Core also makes sense to me, and I think we should just go with whatever the editor finds most convenient. If they delay LC or we want them to progress faster for patent policy reasons, that's a separate story. I do think the HTML5 spec is ridiculously large and could use with being split up into several mostly independent chunks. A spec shouldn't be so large that you don't want to close the tab because it takes too long to reopen. But it also shouldn't be so small that you have to keep a dozen different tabs open to figure out anything nontrivial. CSS3 specs are far too small. I think DOM Core is currently in a reasonable middle ground where it's still fair to add more material to it if it's relevant, just not an excessive amount more. I'm not talking about authors, I'm talking about browser vendors. As someone looking to implement a spec, I'm very interested in knowing which parts of the spec has consensus and which ones doesn't. This is a separate issue. New features and old features have to go in the same drafts regardless, for sanity's sake. If we want to mark them up clearly, we have to do this whether they're in a big spec or a small spec.
Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Aug 22, 2011, at 11:47 , James Graham wrote: I don't really understand your point here. If you used the smaller document presumably you could just have easily have read the relevant chapter from the larger document. [...snip...] Small specs encourage people - including the spec editors - to perceive that features are more self-contained than they really are, leading to the problem of important detail dropping into the gaps between the specs. I don't understand your point here. If you used the larger document presumably you could just have concatenated all the dependencies into one. More seriously, if we don't want to rathole forever on this we have to collectively admit that any supposed rule about how people might review or edit a document based on its size or componentisation are, in the absence of hard data, just subjective bollocks. Different people read differently, different editors edit differently, and at the end of the day all you'll get out of such a discussion is a rehash of space vs tabs, vi vs Emacs, boxers vs briefs, etc. It doesn't matter that the truth is obviously on the side of space, vi, and thongs you'll still get no consensus. What we *may* be able to come up with if we really intend to reach some form of agreement here is a set of best practices in document engineering. This would involve answering such questions as: • Is it easier for twenty editors to work on a single document or on twenty smaller documents? And by this I mean measurably — not personally. • What is the best way of capturing the dependencies that a testable assertion may have on other testable assertions, or on a set of defined terms, and does that best way benefit more from a given organisation of content or another? • What is the best approach with regards to patent policy (in a realistic world)? This must take into account such aspects as the political necessity of having multiple groups, time to Rec, feature-completeness of FPWD (since that's when the first exclusion period runs from), etc. • Several others I won't bother to list just yet. If we can't be bothered with discussing this right then we should probably exit the rathole and leave it up to editors of individual documents. FWIW my personal experience is very much in line with Jonas's. Additionally, having releases of a spec makes it possible to know what browser vendors and other significant players agree on. A ever changing slowly evolving spec doesn't say what browser vendors agree is good as opposed to what the editor happened to have put in since the various stake holders took a look at it. What browser vendors agree on is entirely unimportant to authors. What they care about is what actually ships. Once things are shipping browser vendors typically don't have much leeway to change things even when they all agree that it would be a nice idea. Right, but that's a non-sequitur to Jonas's point. Having snapshots of consensus that can be distinguished from whatever the editor just happened to braindump into the spec is very useful to anyone joining the conversation mid-way. The alternative is trawling through diffs and older thread which is error-prone, a barrier to entry, and conducive to permathreads. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
Le 22 août 2011 à 05:47, James Graham a écrit : Small specs encourage people - including the spec editors - to perceive that features are more self-contained than they really are Note that in some circumstances it might have some benefits in forcing orthogonality. Our tools and cultural usage of tools are shaping the way we think both ways but… What they [authors] care about is what actually ships. Not the point. I think Jonas was making. A smaller specification is easier to grasp, and even if authors care about what actually ships, they also like to read the specification be it directly or through a technical writer. Smaller specifications are easier to read for those readers. Robin is making a good point. The same way the document is one agent participating to the way you *design* a technology, it is also a way to design the way we work together. Le 25 août 2011 à 09:19, Robin Berjon a écrit : • Is it easier for twenty editors to work on a single document or on twenty smaller documents? And by this I mean measurably — not personally. When we talk small/big documents, we are not asking the right questions. The way we want to work (editors, wgs, etc.), the type of usage we want for these documents (readers, articles, implementers), the way these documents will be handled by the society (patent policy, references), etc. All of that is what creates the choice. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Mon, Aug 22, 2011 at 2:47 AM, James Graham jgra...@opera.com wrote: On 08/22/2011 11:22 AM, Jonas Sicking wrote: http://www.whatwg.org/specs/web-apps/current-work/complete/ I *always* used the much smaller document that used to be available here: www.whatwg.org/specs/web-workers/current-work/ I don't really understand your point here. If you used the smaller document presumably you could just have easily have read the relevant chapter from the larger document. The point is that if it's just a chapter in a larger spec, how do I know that there isn't other important information in the larger spec that I have to read in order to get a understanding of the full feature. When implementing a spec, the first thing I'd like to do is to read the whole spec front to back. This in order to get a sense for the various concepts involved which affects the implementation strategy. It is also important as it's required to review the specification. With a spec the size of, for example, the HTML5 spec, this is substantially more difficult. Not only does it take significantly longer to read the full HTML5 spec if all I want to implement is the pushState feature. It's also impossible to hold the fully spec in memory, even at a high level. Why would you read the whole spec to implement features contained in a single subsection? Alternatively, why wouldn't you read the whole HTML5 spec to implement web workers since there are normative dependences? It seems very arbitrary to base your choice of what is enough background information on someone else's choice of multiple files vs multiple sections in a single file. Small specs are absolutely more easily implemented and reviewed. I think this is an illusion. Self-contained features are more easily implemented and reviewed. There is no reason that a relatively self-contained feature can't be a section of a larger document. But how will I as a reader know if the feature is self contained or not? Small specs encourage people - including the spec editors - to perceive that features are more self-contained than they really are, leading to the problem of important detail dropping into the gaps between the specs. What people need in order to design good specifications is to have an understanding of the web platform. If they don't have that then they won't design a good spec. I don't see how merging specifications into a larger specifications will increase their understanding. In particular, they need to have an understanding of the features that their spec is related to. We'll help them a lot more by making it easy to research those features, than my merging specs together and hope that that causes them to read more. Additionally, having releases of a spec makes it possible to know what browser vendors and other significant players agree on. A ever changing slowly evolving spec doesn't say what browser vendors agree is good as opposed to what the editor happened to have put in since the various stake holders took a look at it. What browser vendors agree on is entirely unimportant to authors. What they care about is what actually ships. Once things are shipping browser vendors typically don't have much leeway to change things even when they all agree that it would be a nice idea. I'm not talking about authors, I'm talking about browser vendors. As someone looking to implement a spec, I'm very interested in knowing which parts of the spec has consensus and which ones doesn't. / Jonas
Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On 08/22/2011 11:22 AM, Jonas Sicking wrote: http://www.whatwg.org/specs/web-apps/current-work/complete/ I *always* used the much smaller document that used to be available here: www.whatwg.org/specs/web-workers/current-work/ I don't really understand your point here. If you used the smaller document presumably you could just have easily have read the relevant chapter from the larger document. When implementing a spec, the first thing I'd like to do is to read the whole spec front to back. This in order to get a sense for the various concepts involved which affects the implementation strategy. It is also important as it's required to review the specification. With a spec the size of, for example, the HTML5 spec, this is substantially more difficult. Not only does it take significantly longer to read the full HTML5 spec if all I want to implement is the pushState feature. It's also impossible to hold the fully spec in memory, even at a high level. Why would you read the whole spec to implement features contained in a single subsection? Alternatively, why wouldn't you read the whole HTML5 spec to implement web workers since there are normative dependences? It seems very arbitrary to base your choice of what is enough background information on someone else's choice of multiple files vs multiple sections in a single file. Small specs are absolutely more easily implemented and reviewed. I think this is an illusion. Self-contained features are more easily implemented and reviewed. There is no reason that a relatively self-contained feature can't be a section of a larger document. Small specs encourage people - including the spec editors - to perceive that features are more self-contained than they really are, leading to the problem of important detail dropping into the gaps between the specs. Additionally, having releases of a spec makes it possible to know what browser vendors and other significant players agree on. A ever changing slowly evolving spec doesn't say what browser vendors agree is good as opposed to what the editor happened to have put in since the various stake holders took a look at it. What browser vendors agree on is entirely unimportant to authors. What they care about is what actually ships. Once things are shipping browser vendors typically don't have much leeway to change things even when they all agree that it would be a nice idea. We should fix the authors need to know what is stable problem by understanding it is actually an authors need to know what is shipping problem and implementing something like caniuse.com directly in the spec, with links to the relevant parts of the testsuite where appropriate.
RE: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Tue, 16 Aug 2011, Adrian Bateman wrote: At Microsoft, we also prefer smaller more specific specifications for all the same reasons that it makes sense to engineer software in smaller, more modular parts. * It is easier to implement and test smaller modules. Developers find it easier to focus on one thing and it is easier for testers to do a thorough job of preparing a test suite. This doesn't apply to specs, since smaller specs usually just means that the same complicated feature is now split over multiple specifications. This actually makes testing harder, since you have to try to work out how the specification work together rather than having just one document that defines the behaviour. * It's much easier to measure done when dealing with a smaller spec. Specifications are never done, however small. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Thursday, August 11, 2011 3:29 AM, 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.
At Microsoft, we also prefer smaller more specific specifications for all
the same reasons that it makes sense to engineer software in smaller, more
modular parts.
* It is easier to implement and test smaller modules. Developers find it
easier to focus on one thing and it is easier for testers to do a thorough
job of preparing a test suite.
* While it is a little harder to make well-defined interfaces between
modules/specs, doing so is part of the engineering process that ensures a
good design.
* It's much easier to measure done when dealing with a smaller spec.
Moving the specification through the stabilisation process, getting complete
implementations, and achieving interoperability is easier when people are
focused on the same set of features. A larger, more monolithic spec always
leads to discussions about which parts are stable or unstable, which are
implemented and how well.
I think it's healthy to debate what should in or out of scope for a
particular document. Ideally this should be based on a set of requirements
or goals for the features. For example, it might be a goal to document the
profile of the DOM that is actually interoperable and in use on the Web
today. It might be a goal to add new features to this DOM that reduces the
amount of code necessary to perform a set of common tasks. It might be a
goal to add capabilities that improve performance of certain scenarios
popular in script libraries.
Microsoft is prepared to contribute more editing resources to the DOM
space once we establish the scope and structure of the future work.
Jacob has been assisting Doug with DOM L3 Events and moving this forward
is our highest priority here.
Cheers,
Adrian.
RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
[ 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 would also be acceptable.
2. The scope of the document is unclear. Microsoft believes that the document
should focus on core DOM interfaces to improve interoperability for DOM Core
in the web platform and to incorporate errata. If there are problems with
other specification such as Traversal, those documents should be amended.
This functionality shouldn't be pulled into DOM Core. We believe improvements
for mutation events should be kept a separate deliverable for this working
group (ADMN).
We would prefer to see these issues addressed before moving ahead with
publication.
Thanks,
Adrian.
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.
