Re: Liason statement from JSR 280: WheelEvent and ProgressEvent usage

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