[DPF]Event categories underspecified in section 5

Hi Jeremy,

This message contains a response to comments on

http://www.w3.org/TR/2004/WD-DPF-20041122/

s16.
Event categories underspecified in section 5

The fifth para of section 5 sketches the use of wildcards to create
event categories. This sketch is insufficiently complete to
build interoperating implementations.


The DPF team would like to inherit the DOM 3 event interfaces,  
however at the time of this writing the DOM 3 events was a Note vs a  
specification. As such, we decided to defer inheriting the interfaces  
until a W3C group picked up the DOM 3 interfaces and moved on from a  
Note stage to a draft stage.

I believe Dave Ragett had an action item (not last week rather the  
week before) to speak to the DOM people asking them what is the  
status of this work.

April 31st 2005: text response: The DPF WG acknowledge the ambiguity  
in using wildcards to specify event categories and as such have  
modified the notion of event categories and their usage in section 5  
to be more in line with the DOM 3 Event Note. The text now reads:

An event category is represented by a namespace URI and a local name.  
Event categories allow listeners to be registered for a hierarchy of  
DPF events rather than for a specific event type. For example, events  
denoting an asr connection status can be associated with the  
following three categories {"http://www.example.org/2003/voicexml",  
"connection"}, {"http://www.example.org/2003/voicexml",  
"connection.disconnect"} or {"http://www.example.org/2003/voicexml",  
"connection.disconnect.hangup"}. An event listener that wishes to be  
notified on the overall status of an asr connection would register  
for the first category of events, and would thus be notified upon asr  
engine being connected, disconnected, and when disconnected if it was  
a hangup or not. On the other hand, an event listener that wants to  
be notified only on hangup calls would register for the last event  
category.

For the type in the methods addDPFEventListener and  
removeDPFEventListener the text is as follows:

The type parameter specifies the type of event for which the listener  
wants notification. This paramenter can also be used to register for  
category of events, rather than for a specific event; this assumes  
that event categories are expressed as a hierarchy of names. See  
Section event process model for examples of event categories.

-Keith Waters

Received on Friday, 3 June 2005 18:11:19 UTC