RE: [Widex] Updated Widex framework draft

[Dave Raggett <[e-mail]>]

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

On Fri, 2 Jun 2006, Jin Yu wrote:

> In the current draft, there are two ways to attach event listeners 
> to a node in the DOM tree: at programming level using DOM3's 
> EventTarget interface, and at document level using XML events and 
> ad-hoc syntax.
>
> By "programming level", I assume what it means is for the 
> application code to use the DOM3 EventTarget API in the virtual 
> view / DOM at the server side (not the real view / DOM at the 
> renderer side); and then those API calls get serialized into 
> WO.Selector messages and delivered to the renderer.
>
> DOM3 uses the term "programming level" because it doesn't have 
> remote events in mind. "Programming" means using script to attach 
> listeners to nodes on the client side. For us, I think what's 
> important is WO.Selector messages, and how the messages are 
> generated is not a big concern. Of course, we could mention that 
> one possibility is for the server side toolkit to offer DOM3' 
> EventTarget API to operate on the virtual view.
>
> So I would re-categorize the ways to attach event listeners to a 
> DOM node - inline (within UI DOM tree) or external (outside of UI 
> DOM tree):

I appreciate the desire to make the draft easier to understand,
but I don't think your suggested wording is quite right, however
with a few email exchanges, I am sure we can work something out.

The overview in section 3.1 attempts to describe how event listeners 
are bound using existing mechanisms:

   a) via the DOM EventTarget interface
   b) via markup

Which of these two is better is context dependent and not something
that Widex should take a position on.

It then outlines the means by which a Widex Server and Renderer
can arrange for event listeners that forward events from the
Widex Renderer to the Widex Server. I think we agree that at
a high level this comes down to:

  1) by prior arrangement
  2) a list of events passed at session establishment
  3) dynamically during the application session

We agree that there are two ways for the Widex Server to dynamically 
add event listeners, one being based upon updating the markup 
through WO.Update messages and the other that uses WO.Selector
messages to directly invoke the EventTarget interface.

Not all event listeners will forward their events to the Server,
as markup languages may include local scripts. These could bind
event listeners via either markup or the EventTarget interface.
I don't think the terminology of inline and external listeners
quite works. For instance, is an event listener bound through
a line of script in a linked script file inline or external?
It isn't inline in the markup, and yet it doesn't forward the
event to the Widex Server.

I will try to come up with proposed rewording for sections 3.1
and 4.3 to make the document clearer.

BTW to support WO.Selector, I have proposed an extension to the DOM3 
Event specification. The idea is to define a pair of new events that 
are associated with adding or removing event listeners. If you think 
in terms of synchronizing DOM trees for the MVC View, then the 
action of adding a listener to the View results in the generation
of a DOM AddListenerEvent that the Widex Server then forwards to the 
Widex Renderer to synchronize the Renderer's copy of the DOM tree. 
This works in just the same way as for DOM Mutation events. If 
this proposal is accepted, the REX specification would be extended 
to provide an XML serialization for the new events.

Regards,

  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)

iD8DBQFEgrynb3AdEmxAsUsRApSdAKDfZMEt2CNZKuD5pvhpgbMA52fDcgCgm5lw
UCUf/SPLCd81JLtGgzIMLm8=
=/DMz
-----END PGP SIGNATURE-----

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