RE: [Widex] Working group last call (WGLC) for Requirements: draft-ietf-widex-requirements-01.txt

["Jin Yu" <[e-mail]>]

> Event filtering could be:
> 
>    a) by prior arrangement
>    b) negotiated at the start of the session
>    c) dynamically updated during the session

Yes, and I think the dynamic part is essential, since most applications will
very likely change their event handling behavior at runtime. That is why I
see the need of a WO for event selection.

> Session initiation is out of scope for REX, but we could support
> the means to dynamically add or remove event listeners during
> the session via introducing a pair of new events for that purpose
> as you suggest. I could draft something on this for the REX mailing
> list.
> 
> For Widex, we could explore the idea of negotiating event selection
> at session initiation.
> 
>    a) a list of explicit event names
>    b) a list of event catgories
>    c) a reference to a list of event names/event categories
> 
> Event categories are something that was introduced by the W3C Voice
> Browser working group for VoiceXML and CCXML. They defined event
> names hierarchically and could name categories of events by
> reference to this hierarchy, e.g. there are a set of events
> 
>       error.connection.noauthorization
>       error.connection.baddestination
>       error.connection.noroute
>       error.connection.noresource
>       ...
> 
> you can specify behavior for a specific event, for all
> error.connection events, or more generally for all error events.

Event categorization is a great concept. But that could be left to the
specific UI languages. The protocol should be just concerned with some XML
namespace qualified event name; whether that name is a concrete event or an
event category could be interpreted by the UI language in use.

> One issue is where the event listener is attached to the DOM tree
> and whether it is invoked in the bubble or capture phase. This only
> matters when there is another event listener that is invoked prior
> to the server's event listener, as then there may the possibility of
> the event being cancelled by the earlier listener.
> 
> I don't believe it makes sense to allow the server's event listener
> to be able to cancel events, as this would introduce a significant
> latency into event handling in the client. For this purpose, the
> event object, that is passed to the server by the widex
> implementation, would have the DOM attributes bubbles and cancelable
> set to false.

I agree. Actually I believe the DOM event capturing / bubbling model may not
fit well with a network UI environment. I think we should not restrict
ourselves to DOM style events. What's more appropriate is a *delegation"
based event model, which is used by popular desktop GUI toolkits such as
.NET WinForms and Java Swing. In this model, one would attach event
listeners (or event handlers in .NET WinForms) to a specific UI component
for a specific event type. This allows for a loose coupling of UI events and
application logic, and it also minimizes event traffic.

> You also talk about UI initialization. I think this can be handled
> as part of the UI markup language, and also by additional events
> sent from the server to the widex renderer. These events are outside
> the scope of Widex, and would need to have their semantics and XML
> serialization defined in separate specifications.

What do you mean by "UI initialization"? I think I was talking about UI
state synchronization in my message. Are you referring to something in the
XUP spec?

> For REX, it will be easier if we stick to the existing DOM events
> so that we can limit the scope of what needs to be specified for
> the processing and serialization of these events. I think we will
> be able to provide an algorithm for describing the serialization
> of these events from their IDL definitions.

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/widex