Re: Comments on DOM Level 3 events

Ken,

please find the DOM WG response to the VoiceXML WG. Given that we
rejected your comments, let us know if the VoiceXML WG wishes that the
DOM WG reconsiders the decisions.

Thank you,
Philippe


> Ordering of Event Groups
>
> Even though the specification supports ordering of events within a
> group, it doesn't support the ordering of events between event groups.
> Some of the requirements we're considering for VoiceXML 3.0 include
> changes to the 2.0 event model, in particular handling external
> asynchronous events.  One potential use of ordered event groups would
> be to include 'standard' VoiceXML events in one group, and 'external'
> asynchronous events in a second group.  It may also be useful to
> enable prioritization of events, assigned by the interpreter developer
> and possibly even within an application by the developer. For example,
> external events may need to be handled at a higher priority than other
> events; on the other hand, it might be necessary in some circumstances
> to allow the developer to block some or all events by priority.

Having ordering of Event groups would require additional methods to give
the ability to control the order: moving a group earlier in the
invocation order, etc. We concluded in the past
that such functionalities didn't need to be exposed to the end
user. Implementations are then free to have an underlying order between
groups. Not exposing such functionalities means that VoiceXML
implementations won't be able to implement the Voice Event system on top of a
generic DOM Events implementation since it will require to modify the
generic DOM Events implementation to introduce group ordering (it
modifies the dispatch). We didn't see enough interest for the moment to
impose this new set of functionalities to all DOM generic
implementations. Therefore, we decided to not address this requirement.

> Event selection
>
> An event handler is selected (see sect 5.2.4 Catch Element Selection
> http://www.w3.org/TR/voicexml20/#dml5.2.4) based on several conditions
> that are evaluated at the event throw time. The count attribute
> specifies the occurance for that event; the cond attribute is an
> ECMAScript expression which specifies whether the event applies at
> that time.

One can imagine lots of possible conditions and the count attribute is
only one possibility. Implementing the count attribute functionality on
top of a DOM generic implementation is very easy to do: it requires
introducing a wrapper on top of the event listener in order to take care
of the count. Therefore, we decided to not address this use case.

> Hierarchical Namespace
>
> In Section 1.5.3, you discuss the concept of the hiearchical name
> spaces that we've included in VoiceXML, but it isn't clear how this is
> compatible with your specification. 

An example of such use is provided in the section 1.5.3, "Using VoiceXML
Events".

> We have found it to be a very powerful mechanism for selecting
> categories of events, or as needed, subcategories as well.  It would
> be helpful to have the DOM Events spec support this.

The DOM Event model do support the concept of hierarchy support, as
shown in section 1.5.3. It is called event categories in the DOM Event
Model. However, the DOM API itself does not expose those DOM Event
categories i.e. you have no ability to register an event listener for a
specific event category (as mentioned in section 1.5.1). Again,
implementing event categories on top of a DOM generic implementation
would require modifying the underlying implementation first since it
modifies the dispatch. We didn't see enough interest for the moment to
impose this new set of functionalities to all DOM generic
implementations. Therefore, we decided to not address this requirement.

Received on Thursday, 24 July 2003 09:55:32 UTC