RE: [Widex] Proposed rewording for Framework draft

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

On Fri, 16 Jun 2006, Jin Yu wrote:

>> So how about:
>>
>>   In an implementation where the Widex Server maintains
>>   an explicit XML DOM for the View, changes made by the
>>   Widex Server to this 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.
>
> Sorry but I'm still a bit confused about the meaning of "explicit 
> view", after your explanation above and Vlad's explanation in the 
> other email:
>

Vlad writes:

>> The "explicit view" on the Widex Server is when the UI exported 
>> through Widex is of a desktop application, case in which a 
>> physical view is kept also on the Widex Server.

Jin responds:

> What's the difference between desktop app and non-desktop app? If 
> you are referring to web apps, then I don't see a difference here. 
> In both cases, the server would keep a virtual DOM / view (e.g. 
> HTML DOM for web app, XUL DOM for desktop app), and the physical 
> view is kept in the renderer.
>
> Or perhaps when you say desktop app, you are referring to 
> X11-based app. In that case, the roles are reversed. The server is 
> indeed keeping a physical view, whereas the client is keeping a 
> virtual view. To me, Widex is the reverse of X11, so I guess our 
> Widex server shouldn't be keeping physical view.

I believe that whether or not the Widex Server maintains an
explicit in-memory XML DOM tree for the View is implementation
dependent and shouldn't effect the Widex protocol. If this is
just a question of wording, will the following work for you?

  In an implementation where the Widex Server maintains
  an explicit XML DOM for the View, changes made by the
  Widex Server to this 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, that is, an in-memory XML DOM tree, as this is
  an implementation dependent design choice.

Regards,

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

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

iD8DBQFEktjfb3AdEmxAsUsRAoc/AJ4vOiLTWkBOqNnUNibGCH5jeOHFswCg0n5V
21JvzQVBhuj257SuWnyvvAk=
=QM11
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex