RE: [Widex] Proposed rewording for Framework draft

[Dave Raggett <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 14 Jun 2006, Jin Yu wrote:

> Just want to clarify - later on you proposed to remove this 
> paragraph (#1 and #2), so the above replacement wouldn't be used 
> anyway?

Correct.

> We may also want to say something about the behavior of multiple 
> event listeners (a mix of local and remote listeners) for the same 
> event. For example, in XUP, if a local listener can fully handle 
> an event locally, it can prevent a remote listener from being 
> called.

I think that comes down to the processing model for events. In the 
case of DOM events, there is provision to stop propagation and to
prevent the default handler from being invoked. It is therefore a
matter of where the remote event listener is attached. A local
handler could then prevent the remote event listener from being
invoked. The otherway round is more complicated. The stub used
in the Widex Renderer could stop further propagation, but there
would be undue latency to allow the corresponding handler in the
Widex Server to be able to do so.

We could include some text on this in the Widex Framework draft,
but is it really necessary? It seems like being at a different
level of detail.


>> I suggest we add something about how the MVC pattern allows
>> server-side operations on the DOM to be reflected to the
>> Widex Renderer as a way of helping to address the concerns
>> over the terminology of DOM Mutation events.
>>
>> How about:
>>
>>   With the Model-View-Controller design pattern, updates to
>>   the (virtual) DOM tree held by the Widex Server are reflected
>>   as WO.Update messages that in turn result in the Widex
>>   Renderer updating its copy of the DOM tree to match the
>>   changes made by the Widex Server. A similar process occurs
>>   when the Widex Server adds or removes event listeners,
>>   where these changes are mediated by WO.Selector messages.
>
> Yes, I think this is a good explanatory text.
>
>>   In a little more detail, changes made by the Widex Server
>>   to the XML DOM for the View, result in DOM events, e.g.
>>   DOM Mutation events. The Widex Framework in the server
>>   (as shown in Figure 1) can listen for these events to
>>   generate the corresponding Widex messages. The Widex
>>   Framework in the Renderer interprets these messages to
>>   reflect the changes to its copy of the XML DOM for the
>>   View. Note that the Widex messages are independent of
>>   whether the Widex Server has an explicit or a virtual
>>   View.
>
> I think this is more like an implementation suggestion (i.e.
> using DOM mutation events on the server side). There are other 
> implementation techniques for the server to trace and serialize 
> the UI updates. For example, in the OpenXUP server, we don't use 
> DOM events at all for performance reasons. The server has a UI 
> tracker, which tracks every API calls to the UI tree; and at the 
> end of the request processing, the content of the UI tracker is 
> serialized into UI updates and sent to the client.

Agreed, but what should we say if anything in the Widex Framework
draft?

>> We can take up the terminological issue of events versus
>> actions in the REX specification. I don't think we need
>> to cover that in Widex where we seem have consensus on
>> the three kinds of messages (Update, Event, and Selector).
>
> Yes, Widex's terminology is fine. My problems are with REX ...

Fine, I will see what can be done to resolve that in the W3C
work.

  Dave Raggett <[e-mail]>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett [phone] (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEkR+Hb3AdEmxAsUsRAtoBAKCB+xGTKteAqbiRZ4g62cbu3gmCpwCghhER
aKmbcesy1PQ6CadaPUM0cyg=
=v/GY
-----END PGP SIGNATURE-----

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