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