Subject: RE: [Widex] Updated Widex framework draft

From: "Jin Yu" <[email-masked]>
Date: Fri, 2 Jun 2006 18:20:45 -0700

Hi,

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):

- inline listener specification

This includes ad-hoc syntax from various UI languages, e.g. HTML' onClick
attribute. In addition, one could use the global attributes from XML Events if
the hosting UI language supports them. In this category, WO.Update messages
should be used to maintain the listeners.

- external listener specification

This involves using WO.Selector messages to add / remove / update event
listeners in the renderer. The messages would carry the generic <listener>
element from XML Events. For example:

<addEventListener>
  <listener id="ls1" event="sul:mouse-click" observer="aCircle"/>
</addEventListener>

<removeEventListener>
  ...
</removeEventListener>

The "handler", "phase", and "propagate" attributes of the listener element may
not be relevant to network event delivery, but we can worry about that later in
the Message Formats draft.

The benefit of using external specification is that it's more flexible and
reusable (just like the CSS case).

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, May 31, 2006 4:31 AM
> To: [email-masked]
> Subject: [Widex] Updated Widex framework draft
>
> Hi, 
> Updated version of the Widex framework draft available at 
> http://www.kolumbus.fi/vlad.stirbu/draft-stirbu-widex-framework-01.txt. 
> It will be available shortly also in the IETF drafts repository.
> 
> Vlad

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

---

From: Dave Raggett <[email-masked]>
Date: Sun, 4 Jun 2006 11:57:39 +0100 (BST)

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 <[email-masked]>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

---

From: "Jin Yu" <[email-masked]>
Date: Sun, 4 Jun 2006 13:56:38 -0700

>   3) dynamically during the application session

Yes, I agree.

> messages to directly invoke the EventTarget interface.

Here is my understanding of how the EventTarget interface could be used to add /
remove listeners:

1. application code on the server side uses the interface to operate on the
virtual view / DOM; the server toolkit then serializes the interface calls into
WO.Selector messages.

2. the renderer receives the WO.Selector messages and then uses this interface
to manipulate the event listeners. Note that in this case it is the renderer
implementation that is using the interface.

3. application code on the render side (e.g. JavaScript) uses this interface to
manipulate the event listeners. In this case, the EventTarget interface has
nothing to do with WO.Selector messages.

So, "programming level" is not equivalent to WO.Selector messages, because:

- as I said in #3, script manipulation on the renderer side has nothing to do
with WO.Selector messages. Actually, I don't think #3 is relevant to our
discussion here; it's outside of the scope of Widex.

- using EventTarget is just one way of implementing and generating WO.Selector
messages. For example, one could have listener specifications in some
server-side template, and then the template could be loaded by the server to
output WO.Selector messages.

> event to the Widex Server.

Yes, you are right; external vs. inline may not be accurate in this case. I
think we agree on principals there are two ways to manage listeners, through
WO.Update messages and WO.Selector messages. I just don't feel very comfortable
with "programming level" being the defining factor, for the reasons stated
above.

Also, since you mentioned it, I'm wondering if it makes any sense to distinguish
local vs. remote event listeners? By local, I mean events are handled locally by
some scripts and not sent to the server; and for remote, the events will be sent
to the server and handled remotely. I think we are more concerned about remote
events, but of course, WO.Selector messages could include both local and remote
event listeners.

> to provide an XML serialization for the new events.

Yes, I think this will be great.

BTW, I have a terminology issue w.r.t. DOM3 Event and REX. I think the term
"event" is overloaded: mutation to the DOM is not the same as mutation event. I
regard the first as the "action" and the latter as the "event", and that action
triggers event. Therefore, DOM mutations trigger DOM mutation events. Obviously
here we are more interested in DOM mutations, not DOM mutation events.

The REX spec treats UI updates as DOM mutation events, which is somewhat
confusing. Similar concern has been raised in the public-webapi mailing list
(<http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0030>).

The same applies to the event listeners, so I would call it AddListenerAction,
rather than AddListenerEvent.

Regards,

Jin