Arbortext XML Events CR implementation feedback--target attribute

This is Arbortext's feedback/comment on the XML Events CR at:
http://www.w3.org/TR/2003/CR-xml-events-20030207/ .

Arbortext uses XML Events in our dynamic dialogs implementation
of our XML based editing/publishing/content management products
Epic Editor and E3.  The following comments come from our primary
engineer in this area.  (The comment is in two parts: the first
was the original statement, and the second is some follow-up after
discussion with our DOM WG member.  I provide both comments in the
hopes that the more input we give, the more helpful it will be.)

-----

Arbortext have implemented W3C XML Events.

I found the spec well written.  There are a lot of examples, and these
examples helped us understand the spec.  They also gave us ideas on its
usage.  This spec was great for our dynamic dialogs feature because we
were able to provide event handling for this feature by utilizing our
existing DOM Level 2 Events implementation.

The only wrinkle I found was the target attribute.  In general, XML
Events follows DOM Level 2 Events, but the target attribute seems to do
something beyond the functions of DOM Level 2 Events.  We found that
implementing this attribute would need some code changes, so we didn't
do it.  The target attribute was one of the only two XML Events
functions that we didn't implement in our first version of
implementation.  Another one was the external event handler, but the
external event handler is an optional function of XML Events.

Since the target attribute is a function that DOM Level 2 Events doesn't
provide, there should be very good reasons that XML Events requires it.
I think these reasons should be mentioned in the spec because other
people might have the same doubt I had.  In our application the target
attribute is insignificant because we cannot think of a case that a user
needs it.

---

[After some more discussion] I agree the target attribute has
some value, especially in the cases that the handler is not a script.
However, I feel the target attribute is not the best design.

In this example:

  <listener event="click" observer="para1"
       target="link1" handler="#clicker"/>

If we are listening to the events for "link1", I don't see a good reason
to set the observer to "para1" because setting the observer to "link1"
has almost the same result.  (The difference of the results is not
something we should take advantage of.)

I think instead of having the target attribute, we can add an "atTarget"
option to the phase attribute.  DOM Events has three phases,
CAPTURING_PHASE, AT_TARGET, and BUBBLING_PHASE.  Currently in XML
Events, the phase attribute has two options, capture and default.

If there is an "atTarget" option, the above listener can be changed to:

  <listener event="click" observer="link1"
       phase="atTarget" handler="#clicker"/>

I think this matches DOM Events better.

-----

Paul Grosso, AC rep, Arbortext

Received on Tuesday, 25 February 2003 11:28:29 UTC