Forms WG comments on XML Events 2 Editor's Draft

GENERAL

Comments pertain to http://www.w3.org/MarkUp/2008/ED-xml-events-20080604/

XML Events 2 updates XML Events by transitioning to providing an XML
surfacing of the DOM Level 3 underlying event API, and by adding a Handlers
module where one was not provided in XML Events 1. There is some discussion
as to the possibility of using XML Events 2 over the DOM Level 2 API
instead and this would be of interest to flesh out to provide more guidance
to implementors -- indeed to recast the XML Events 2 spec formally as
pertaining to both DOM2 and DOM3 if possible.

The Informative introduction to the document continues to provide a loose
description of the basic DOM event lifecycle -- a description which leaves
too much ambiguity to be useful as it currently stands, and requires
readers to delve into the underlying DOM Event Recommendations in order to
really understand how things work.  For example, the paragraph begining
"Event flow in DOM3":

   capture phase processing is described as passing down the tree from the
   root to the target -- the underlying DOM3 description makes clear that
   capture phase processing ends at the target's parent element.
   handlers are described as being attachable to any node including root
   and target in "either" phase, when the target in particular participates
   in all three phases ("either" pertaining to a possible set of only two
   phases).
   "a handler can only listen for one phase, to listen for both..." --
   again the language describing phases has not been updated from XML
   Events 1 adequately to reflect the "at-target" phase as a first-class
   part of the event lifecycle.  Further more, a handler using "default"
   processing will listen to two phases (target and bubble) so again this
   language needs to be updated to reflect the more careful semantics of
   DOM3 phasing.
   likewise, the diagram implies graphically that the capture and bubble
   phase processes extend to the target.  The DOM3 document indicates more
   clearly (using dashed line notation) that these phases do not include
   the target but terminate/originate respectively at the target's parent.
   Please consider either using the diagram from the DOM3 spec or using the
   same notation (dashed lines from parent to target) to clearly separate
   capture and bubble phase processing from target phase processing.

CONFORMANCE REQUIREMENTS

There is a casual comment about the draft supporting "chameleon" elements
and attributes (needs reference for those unfamiliar with this pattern) --
but then comments that it's not clear what the implications are for
implementors...can more be said here???

EVENTS MODULE

Observer and targetid are IDREFS -- limited to the current document.
Handler is a URI allowing for references to external documents.  What is
the rationale for treating these two cases differently?  Is there an option
for observer and targetid to refer to external documents?  Please consider
treating observer, target, and handler consistently using xpointer notation
(and then renaming targetid since it will not longer be always an id) to
allow for more general navigation to all three nodes.

Section 3.1 on the listener element, the last paragraph of the targetid
attribute mentions that the author should use observer="link1" and no taret
for the desired bubbling behavior.  The key aspect of the example is to
drop the target, thus observer="para1" as originally coded would work in
this case as well...just a bit confusing for the reader.

At the end of 3.1 there is a note relating to similarities with event
processing in SMIL -- which seems out of place in this document, at least
where the note occurs.  A more complete comparison of event lifecycles in
other XML languages would indeed be of great interest, and suggestions for
how to use XML Events 2 in various profiles or subsets to support them
would be also great guidance for those not currently thinking in terms of
XML or DOM events.


HANDLERS MODULE.

No comments

XPath EXPRESSIONS

There is an Editor's note about the need for compelling use cases for
allowing context to be specified.  For discussion -- we we in XForms have
any such requirements?

Received on Wednesday, 11 June 2008 15:07:23 UTC