- From: nandini <Nandini.Ramani@sun.com>
- Date: Tue, 14 Nov 2006 11:31:07 -0800
- To: Ellen Siegel <Ellen.Siegel@sun.com>
- Cc: "Web APIs WG (public)" <public-webapi@w3.org>, Vincent Hardy <Vincent.Hardy@sun.com>
Ellen, The SVG WG and the WEB APIs WG are having a joint telcon today at noon PDT to discuss alignment of the uDOM and DOM. Maybe you can join the call as well? Please let me know and I will send you dial-in details. -Nandini > WebAPI WG, > > I just wanted to add a few clarifications to Nandini's earlier message > on this topic (see appended message), since our deadline for PDF draft > submission to the JCP is coming up in mid to late December. > > First, although the APIs will be available to whatever applications > choose to use them, 280 (XML API for Java ME) is adding UIEvent > support primarily for JSR 290 and possibly also for 287 should the 287 > EG decide to support these interfaces. Since both 287 and 290 are > SVG-related, support for SVG uDOM UIEvents is fairly important. > However, since 280 is explicitly providing a subset of DOM to the Java > ME platform, we will need to follow the DOM 3 spec rather than the > uDOM spec should there be any incompatible divergence between the two. > > Second, the plan is for JSR 280 to submit a Proposed Final Draft (PFD) > to the JCP in mid December, so in order for us to be able to safely > include these interfaces we need to be certain, or at least nearly > certain, that you folks have finalized the interfaces for DOM 3... we > can't risk including unconfirmed interfaces in 280 that might result > in divergence from the DOM 3 specification. So we would very much > appreciate a fairly firm decision one way or the other before the end > of December (and an assessment of how likely the relevant interfaces > are to be modified by your public review phase). > > Third, the interfaces under discussion (WheelEvent and ProgressEvent) > were an attempt to take the interfaces needed by 290 and/or 287 from > the uDOM specification and align them with pre-existing DOM 3 UIEvent > types by adding the init and initNS methods. > > Finally, it seems that you already have a MouseMultiWheelEvent in > process that is a superset of the WheelEvent interface that we are > proposing. Considering that the WheelEvent is already in the SVG uDOM > specification > (http://www.w3.org/TR/SVGMobile12/svgudom.html#events__WheelEvent), it > seems unfortunate to break the uDOM's alignment with DOM 3 by > creating an event with overlapping functionality but a different > name. If you are sure that the MouseMultiWheelEvent is the plan of > record despite breaking compatibility with the uDOM spec, I'd > appreciate confirmation so that I can discuss with the 290 and 287 > leads whether they can acommodate this new interface in place of > WheelEvent. > > I'd very much appreciate your help in resolving the issues around > these UI Events as quickly as possible, ideally in time for us to be > fairly confident in the timeframe of our PDF release to the JCP. > Please let me know if I can do anything to facilitate the decision > process. > > Thanks, > Ellen > > nandini wrote: >> Dear WebAPI WG, >> I wanted to clarify that the Liaison statement I sent dated Oct >> 10th is only from the JSR-280 EG, not the JSR-287 EG. Sorry for the >> confusion. >> >> Thanks >> -Nandini >>>> >>>> >>>> Dear WebAPI WG, >>>> The following is a Liaison statement from the JSR-287/280 EG. >>>> Based on input from several members, the EG would like to request >>>> the following useful additions to the DOM Level 3 Events >>>> specification. >>>> >>>> 1. WheelEvent >>>> interface WheelEvent : UIEvent { >>>> readonly attribute long WheelDelta; >>>> void initWheelEvent(in DOMString type, >>>> in boolean canBubblle, >>>> in boolean cancelableArg, >>>> in views::AbstractView >>>> viewArg, >>>> in long detailArg);} >>>> void initWheelEventNS( in DOMString namespaceURI, >>>> in DOMString type, >>>> in boolean canBubblle, >>>> in boolean cancelableArg, >>>> in views::AbstractView >>>> viewArg, >>>> in long detailArg); >>>> }; >>>> >>>> 2. ProgressEvent >>>> interface ProgressEvent: Event { >>>> readonly attribute boolean lengthComputable; >>>> readonly attribute unsigned long loaded; >>>> readonly attribute unsigned long total; void >>>> initProgressEvent(in DOMString type, >>>> in boolean canBubblle, >>>> in boolean cancelableArg, >>>> in views::AbstractView >>>> viewArg, >>>> in long detailArg);} >>>> void initProgressEventNS( in DOMString namespaceURI, >>>> in DOMString type, >>>> in boolean canBubblle, >>>> in boolean cancelableArg, >>>> in views::AbstractView >>>> viewArg, >>>> in long detailArg); >>>> }; >>>> >>>> Best Regards, >>>> Nandini Ramani >>>> >>>> >>> >>> --Robin Berjon >>> Senior Research Scientist >>> Expway, http://expway.com/ >>> >>> >>
Received on Tuesday, 14 November 2006 20:34:28 UTC