[Widex] Proposed rewording for Framework draft

[Dave Raggett <[e-mail]>]

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

It seems that Jin isn't keen on the use of the term "programming
level" in section 3.1, so how about replacing:

  DOM model describes mainly two ways to associate an event
  listener to a node in the tree:

  1.  at the programming level, using the EventTarget interface as
      specified by DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413]
      or a method specific to the UI markup language.
  2.  at the document level, using XML Events
      [W3C.REC-xml-events-20031014] or an ad-hoc syntax, as the
      ones provided by the UI markup language itself, e.g.  XHTML
      [W3C.REC-xhtml1-20020801] or SVG 1.1 [W3C.REC-SVG11-20030114].

By

  The DOM describes two ways to associate an event
  listener to a node in the tree:

  1.  Using the DOM EventTarget interface as specified by
      DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413] or a
      method specific to the UI markup language.
  2.  Using markup, either with XML Events
      [W3C.REC-xml-events-20031014] or a language specific
      syntax, e.g.  XHTML [W3C.REC-xhtml1-20020801] or SVG 1.1
      [W3C.REC-SVG11-20030114].

And replacing:

  Following the DOM model, associating event listeners to a node
  in the tree at document level is done using WO.Update messages
  as described in Section 4.1, while at the programming level is
  done using WO.Selector messages as described in Section 4.3.

By

  The Widex Framework enables event listeners to be attached
  to DOM nodes using either WO.Update messages as described in
  Section 4.1, or through WO.Selector messages as described in
  Section 4.3.

Which avoids the use of "programming" vs "document level".

However, this leaves open the issue of how to distinguish
local and remote event listeners. The DOM EventTarget interface
only deals with local event handlers. XML Events allows you
to specify handlers via URIs but the assumption seems to be
that these are scripts that are downloaded and executed locally
by the markup language interpreter.

It seems to me that WO.Update messages can only be used to add local 
event listeners, unless there is specific provision for remote event 
listeners in the markup language itself. Remote event listeners can 
be added by WO.Selector messages, or as part of session 
establishment, or by prior arrangement.

I would therefore like to propose that we discard the text:

  DOM model describes mainly two ways to associate an event
  listener to a node in the tree:

  1.  at the programming level, using the EventTarget interface as
      specified by DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413]
      or a method specific to the UI markup language.
  2.  at the document level, using XML Events
      [W3C.REC-xml-events-20031014] or an ad-hoc syntax, as the
      ones provided by the UI markup language itself, e.g.  XHTML
      [W3C.REC-xhtml1-20020801] or SVG 1.1 [W3C.REC-SVG11-20030114].

The text following figure 2 would then be:

  The Widex Framework needs a mechanism by which the Widex
  Renderer determines which events have a remote scope and
  therefore need to be serialized and forwarded to the Widex
  Server. The determination of which events have a remote
  scope could be achieved in one of three ways:

  o  prior agreement between the Widex Renderer and Widex Server

  o  a list of events passed during session establishment

  o  the Widex Server could direct the Widex Renderer to add
     and remove event listeners during the session

  The Widex Framework enables remote event listeners to be
  dynamically attached to DOM nodes during the session using
  WO.Selector messages as described in Section 4.3. Local
  event listeners that are not forwarded to the Widex Server
  may be dynamically attached through WO.Update messages as
  described in Section 4.1, and which update the DOM tree
  that is interpreted by the Widex Renderer.

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.

  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.

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

  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)

iD8DBQFEj/Wmb3AdEmxAsUsRAhJ2AKDIcW3yjcXKKrcyo9L4OcVeIGlAsgCgz8U/
5DWtIcIkPWRG0rFwNy3gAI8=
=5XTI
-----END PGP SIGNATURE-----

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