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/