Re: ISSUE-148 (modularize d3e): Consider modularizing DOM3 Events [DOM3 Events]

Hi, Garrett-

The recorded discussion was not the only presentation of the issue; I 
recorded your issue in full in the issue tracker, and you presented your 
case via email, which is the primary manner in which technical issues 
are discussed in this group; as you mentioned, other people also 
contributed to that thread.

I have recorded your dissatisfaction with the response in the issue 
tracker, and it will be discussed with the Director during the 
transition telcon for DOM3 Events:
   http://www.w3.org/2008/webapps/track/issues/148

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs


Garrett Smith wrote (on 11/10/10 3:19 AM):
> On 11/3/10, Doug Schepers<schepers@w3.org>  wrote:
>>  Hi, Garrett-
>>
>>  We discussed this in a teleconference, and again at the WebApps WG
>>  face-to-face meeting at TPAC (W3C's tech plenary) [1].  Anne van
>>  Kesteren from Opera, the new editor of Web DOM Core, represented the
>>  viewpoint of modularizing DOM3 Events.
>>
>
> The endorsement of the idea for modularization isn't supported by any
> reasoned argument. That doesn't mean that no reasonable argument could
> be made, however unreasoned argument can be and should be and was shot
> down.
>
> It looks like the argument wasn't presented well and if you read over
> it and then contrast to what was carefully thought out and written by
> myself, Sergey Illinsky, Charles Pritchard. The arguments we mentioned
> didn't come up there; there was no talk of keyboard events.
>
> There was a brief endorsement,
> |  shepazu: wansts to modularize
> |
> |    … and Anne wants to modularize more too
>
>
> And then there was brief mention about mutation events and then:
>
> | mjs: my preference would be to move forward but plan [to move things
> |    to DOM Core later]
> |
> |    smaug_: I agree
> |
> |    … let's get DOM3 Events done now
>
> Yes, right now.
>
> Sounds like implementors want a spec right now. Of course, and why
> would they want otherwise?
>
> But what about looking just past right now? Are there longer-term
> (permanent) ramifications of D3E being published as-is? D3E is not
> cohesive, not modular, and all the mistakes that have been made with
> it are causing it to take longer.
>
> What does it take to appreciate what happens when an API is published?
>
> Some of the more specific functionality in D3E has problems and many
> of these have been mentioned.. However the whole spec is a ball of
> mud. I'd rather not be optimistic and say to do a good job or make
> some improvements in various places. It's too big and bloated to
> tackle like that.  Get it organized. Divide and conquer, not the other
> way around.
>
>>  I understand and agree with the goals of modularization, but there are
>>  also other goals that modularization makes more difficult;
>
> What are they?
>
> it's always a
>>  judgment call in deciding which spec covers which functionality.
>>
>>  Anne specifically advocated splitting out parts of DOM3 Events and
>>  putting them instead into Web DOM Core, but the general tenor of the
>>  majority of browser vendors expressed a desire to finalize DOM3 Events,
>>  and did not feel that the benefits of modularizing or otherwise
>>  reorganizing the spec outweighed the benefits of finalizing this spec
>
> "just get it done" -- sounds like panic mode.
>
> <http://www.w3.org/2008/webapps/track/issues/1>
>
>>  with the set of features currently defined.  So, we have resolved not to
>>  modularize the spec in the way you have suggested.
>>
>
> For any other reason that the vendors want something right now? And
> how does not modularizing speed things up?
>
> I think the API design matters. How easily can the API of a published
> TR be changed or modified at a later date? In the discussion you've
> linked, I don't see any proposal for modularity, no rationale, nor any
> plan of attack, not for now, not for later.
>
>>  This is not to say that this may not be revisited in a later DOM spec,
>>  such as Web DOM Core.
>>
>
> The more components that change in any release of a package, the
> greater the work to rebuild, test, and deploy the release. Work takes
> time. I heard mention that the spec is late, (and not to beat a dead
> horse, but again, issue 1). The spec has grown as things have been
> realized. Grown too much. I am not surprised that lumping all of that
> functionality  together (and *geting it done right now*) does not save
> time and effort.
>
>>  Please let us know whether or not you are satisfied with this resolution.
>>
>
> Doesn't sound like a very reasonable solution. I can't think of
> anything else on the matter that hasn't already been ignored,
> misunderstood, top-posted over, etc.
>
>>  [1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0430.html
>>
>>
>>  Regards-
>>  -Doug Schepers
>>  W3C Team Contact, SVG, WebApps, and Web Events WGs
>>
>>
>>  Web Applications Working Group Issue Tracker wrote (on 10/6/10 8:58 AM):
>>>
>>>  ISSUE-148 (modularize d3e): Consider modularizing DOM3 Events [DOM3
>>>  Events]
>>>
>>>  http://www.w3.org/2008/webapps/track/issues/148
>>>
>>>  Raised by: Doug Schepers
>>>  On product: DOM3 Events
>>>
>>>  Garrett Smith
>>>  in<http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0003.html>:
>>>  [[
>>>  I think we're all well aware of the monstrosity that has become D3E.
>>>
>>>  D3E should be cut way back; it is too large and too complicated.
>>>  Individual events and keyboard specificity are not "core" features;
>>>  they are details and particulars of specific events. These events
>>>  should be moved each to a separate specification.
>>>
>>>  Moving specific event specification details to independent
>>>  specifications will help reveal the real "core" of DOM 3 Events; so
>>>  that core can be looked at more closely and independently questioned;
>>>  e.g. "should useCapture be optional" and ditto for the extracted/moved
>>>  event "Should we specify keyCode and charCode".
>>>
>>>  To put this idea to action, I suggest starting with the a complicated
>>>  part of the spec that seems the least core. For example, keyboard
>>>  events, which itself is about 30 pages long. I would extract that from
>>>  the spec and move it to another document and see how it reads on its
>>>  own.
>>>
>>>  If further help is wanted, then a request can be made for an associate
>>>  editor.
>>>  ]]

Received on Wednesday, 10 November 2010 14:39:46 UTC