W3C

XML Events Candidate Recommendation Review Disposition of Comments

7 May 2003

This version:
http://www.w3.org/MarkUp/2003/xml-events-cr-doc-20030507
Latest version:
http://www.w3.org/MarkUp/xml-events-cr-doc
Editors:
Shane McCarron, Applied Testing and Technology, Inc.

Abstract

This document outlines the way in which the HTML Working Group addressed the comments submitted during the XML Events Candidate Recommendation review period.

Status of this document

During the Candidate Recommendation review period for XML Events, a number of comments were received from both inside and outside of the W3C. This document summarizes those comments and describes the ways in which the comments were addressed by the HTML Working Group.

Note that the majority of this document is automatically generated from the Working Group's database of comments. As such, it may contain typographical or stylistic errors. If so, these are contained in the original submissions, and the HTML Working Group elected to not change these submissions.

This document is a product of the W3C's HTML Working Group. This document may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use this document as reference material or to cite it as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.

This document has been produced as part of the W3C HTML Activity. The goals of the HTML Working Group (members only) are discussed in the HTML Working Group charter (members only).

Please send detailed comments on this document to www-html-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on HTML features takes place on the mailing list www-html@w3.org.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Table of Contents

IssueStateResolution
6246: script as an XML Event handler Feedback This is being addressed in a companion document.
6277: Arbortext XML Events CR implementation feedback--target attribute Feedback Based upon comments from other implementors, and a review by the working group, the group elected to not implement this change. They felt that this change would make some things more difficult, while not really improving the implementability of the target attribute.
6267: Handlers' nature Feedback Fixed.
6290: Comments for CR-xml-events-20030207 Feedback Fixed. In the case of RFC 2119 references, we have changed the offending items so they use different terms.
6293: Comment for CR-xml-events-20030207 Feedback Fixed.
6296: CR XML Events - 2.1 Feedback Fixed.
6340: XML Events module implementations Feedback The implementations will be harmonized between the drafts, and will be stored in a consistent, non-date space location.

1. XML-Events

1.1 script as an XML Event handler

PROBLEM ID: 6246

STATE: Feedback

NOTES:

  This is being addressed in a companion document.

ORIGINAL MESSAGE:

  From: "David Landwehr" <DLandwehr@novell.com>
  
  From: "David Landwehr" <DLandwehr@novell.com>
  To: <www-html-editor@w3.org>
  Subject: script as an XML Event handler
  Date: Tue, 04 Feb 2003 10:07:44 +0100
  Message-Id: <se3f9112.095@cpl-emea-mail1.cpl.novell.com>
  X-Archived-At: http://www.w3.org/mid/se3f9112.095@cpl-emea-mail1.cpl.novell.com
  
  Hi,
  
  It seems that the script element is not specified as an XML Event
  handler and what the behavior should be. Is this intentionally and if so
  what would the example from the XML Event specification mean in XHTML
  2.0?
  
  Example from XML Events (2.3.1 ex. 1):
  <script type="application/x-javascript"
          ev:event="submit" ev:observer="form1">
     return docheck(event);
  </script>
  
  Best regards,
  David

1.2 Arbortext XML Events CR implementation feedback--target attribute

PROBLEM ID: 6277

STATE: Feedback

NOTES:

  Based upon comments from other implementors, and a review by the working group,
  the group elected to not implement this change. They felt that this change
  would make some things more difficult, while not really improving the
  implementability of the target attribute. 

ORIGINAL MESSAGE:

  From: Paul Grosso <pgrosso@arbortext.com>
  
  From: Paul Grosso <pgrosso@arbortext.com>
  To: www-html-editor@w3.org
  Subject: Arbortext XML Events CR implementation feedback--target attribute
  Date: Tue, 25 Feb 2003 09:18:52 -0600
  Message-Id: <4.3.2.7.2.20030225090832.028142c0@172.27.10.30>
  X-Archived-At: http://www.w3.org/mid/4.3.2.7.2.20030225090832.028142c0@172.27.10.30
  
  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

FOLLOWUP 1:


  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  From: <pgrosso@arbortext.com>
  > This is Arbortext's feedback/comment on the XML Events CR at:
  > http://www.w3.org/TR/2003/CR-xml-events-20030207/ .
  ...
  > 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.
  
  Thanks you for your comments.
  
  I have discussed your comments with other implementors and some users.
  
  The implementors agree that the target attribute is the hardest part of XML
  Events to implement, since it doesn't have a direct one-to-one mapping to a
  DOM Events API. However, they said that your proposal wouldn't make
  implementation significantly easier.
  
  As for usage, there are use cases that are not equivalent to your examples,
  that would not be possible with your suggested change.
  
  You need the target attribute in order to catch an event before it triggers
  any handlers on the target element. Because DOM Events does not give an
  ordering on the handlers of an element, if we replaced the target attribute
  with a target phase, you wouldn't be able to do that; the target attribute
  allows you to use the structure of the DOM tree to prioritize handlers. In
  the words of a commentator:
  
  "the target attribute is more powerful that installing a handler as an
  observer on the same node, because you can prioritize the execution using
  the DOM hierachy (e.g. where you install the handler), but it will only be
  executed when the target was the specified one"
  
  Best wishes,
  
  Steven Pemberton
  

REPLY 1:


  From: Shane McCarron <voyager-issues@mn.aptest.com>
  
  Paul,
  
  I just noticed that you did not receive a (recorded) reply to your comments.  We
  have gotten your comments about the target attribute, and are reviewing them. 
  We will coordinate with you as we develop a working group position.

1.3 Handlers' nature

PROBLEM ID: 6267

STATE: Feedback

NOTES:

  Fixed.

ORIGINAL MESSAGE:

  From: chris___m@hotmail.com
  
  From: "Krzysztof Maczy˛ski" <chris___m@hotmail.com>
  To: <www-html-editor@w3.org>
  Subject: Handlers' nature
  Date: Tue, 18 Feb 2003 20:24:30 +0100
  Message-ID: <BAY1-DAV46cXCXWtjik00005e6c@hotmail.com>
  X-Archived-At: http://www.w3.org/mid/BAY1-DAV46cXCXWtjik00005e6c@hotmail.com
  
  Why do handlers have to be elements?
  From http://www.w3.org/TR/2003/CR-xml-events-20030207/: "The optional handler attribute specifies the URI-reference of an element that defines the action that should be performed if the event reaches the observer."
  From http://www.w3.org/TR/2003/CR-xml-events-20030207/last-call-summary.html: 'handler' should be an idref (not a URI) and reference an <object> 
  No. 'Handler' should be able to reference an external handler. We don't define (in this spec) what it points to, to allow for maximum flexibility. A future companion spec will define options for handlers".
  What seems logical to me is quite the opposite. If there is some resource identifiable with a URI (a script function, an object with a clsid, whatever) suitable for handling events, why should an element be artificially created to de facto only link to it?

FOLLOWUP 1:


  From: "Steven Pemberton" <steven.pemberton@cwi.nl>
  
  > From: "Krzysztof Maczy˛ski" <chris___m@hotmail.com>
  
  > Why do handlers have to be elements?
  
  > From http://www.w3.org/TR/2003/CR-xml-events-20030207/: "The optional
  handler attribute specifies
  > the URI-reference of an element that defines the action that should be
  performed if the event reaches the
  > observer."
  
  > From
  http://www.w3.org/TR/2003/CR-xml-events-20030207/last-call-summary.html:
  'handler' should be
  > an idref (not a URI) and reference an <object>
  > No. 'Handler' should be able to reference an external handler. We don't
  define (in this spec) what it points
  > to, to allow for maximum flexibility. A future companion spec will define
  options for handlers".
  
  > What seems logical to me is quite the opposite. If there is some resource
  identifiable with a URI (a script
  > function, an object with a clsid, whatever) suitable for handling events,
  why should an element be
  > artificially created to de facto only link to it?
  
  You are right, the word 'element' is misplaced; 'resource' is a better term
  to explain what is intended.
  
  Best wishes,
  
  Steven Pemberton
  
  

1.4 Comments for CR-xml-events-20030207

PROBLEM ID: 6290

STATE: Feedback

NOTES:

  Fixed.  In the case of RFC 2119 references, we have changed the offending items
  so they use different terms.

ORIGINAL MESSAGE:

  From: Susan Lesch <lesch@w3.org>
  
  From: Susan Lesch <lesch@w3.org>
  To: www-html-editor@w3.org
  Subject: Comments for CR-xml-events-20030207
  Date: Wed, 5 Mar 2003 22:50:17 -0500
  Message-Id: <p05111b02ba8c754cf5e8@[64.134.139.11]>
  X-Archived-At: http://www.w3.org/mid/p05111b02ba8c754cf5e8@[64.134.139.11]
  
  Belated congratulations on your "XML Events" Candidate Recommendation [1].
  Here are just a few minor editorial comments.
  
  In the heading and TOC for 3.1.1, s/usage/Usage/
  s/URI-reference/URI reference/
  In the QName module, s/behaviour/behavior/
  In appendix B, s/SCHEMA/schema/ (I think)
  s/members of the W3C HTML Working Group/participants in the W3C HTML 
  Working Group/
  
  If and when this becomes a Rec, in the appendixes, 
  s/recommendation/Recommendation/
  
  There are a couple of instances of RFC 2119 key words that aren't meant
  as imperatives ("what form that element should take"). You could mark
  up the RFC sense like the example in the W3C Manual of Style:
  http://www.w3.org/2001/06/manual/#RFCs
  
  [1] http://www.w3.org/TR/2003/CR-xml-events-20030207/
  
  Best wishes for your project,
  -- 
  Susan Lesch           http://www.w3.org/People/Lesch/
  mailto:lesch@w3.org               tel:+1.858.483.4819
  World Wide Web Consortium (W3C)    http://www.w3.org/

FOLLOWUP 1:


  From: Susan Lesch <lesch@w3.org>
  
  Hello, Shane,
  
  >  You indicated there were a couple of references to RFC
  >  2119 terms that should not be imperatives.  Can you give us a better
  >  pointer?
  
  Sorry, on second reading this was no big deal. This first one is what
  caught my eye, probably thinking someone searching for testable
  assertions would find the "should":
  
  In 3.1 handler:
         This specification does not mandate what form that element should
         take
  
  http://www.w3.org/TR/2003/CR-xml-events-20030207/Overview.html#section-listener-element
  
  Also in 4. (informative)
         how language designers should name events
  and
         to which you should refer
  
  All the rest seem to be the RFC sense.
  
  -- 
  Susan Lesch           http://www.w3.org/People/Lesch/
  mailto:lesch@w3.org               tel:+1.858.483.4819
  World Wide Web Consortium (W3C)    http://www.w3.org/

REPLY 1:


  From: Shane McCarron <voyager-issues@mn.aptest.com>
  
  Susan,
  
  Thanks for your input.  You indicated there were a couple of references to RFC
  2119 terms that should not be imperatives.  Can you give us a better pointer?

1.5 Comment for CR-xml-events-20030207

PROBLEM ID: 6293

STATE: Feedback

NOTES:

  Fixed.

ORIGINAL MESSAGE:

  From: Susan Lesch <lesch@w3.org>
  
  From: Susan Lesch <lesch@w3.org>
  To: www-html-editor@w3.org
  Subject: Comment for CR-xml-events-20030207
  Date: Thu, 6 Mar 2003 12:42:43 -0500
  Message-Id: <p05111b05ba8d389410d4@[64.134.139.11]>
  X-Archived-At: http://www.w3.org/mid/p05111b05ba8d389410d4@[64.134.139.11]
  
  Sorry to send a mail for such a small detail. The tables in [1] could
  use cellpadding="3" or so.
  
  [1] http://www.w3.org/TR/2003/CR-xml-events-20030207/
  
  -- 
  Susan Lesch           http://www.w3.org/People/Lesch/
  mailto:lesch@w3.org               tel:+1.858.483.4819
  World Wide Web Consortium (W3C)    http://www.w3.org/

1.6 CR XML Events - 2.1

PROBLEM ID: 6296

STATE: Feedback

NOTES:

  Fixed.

ORIGINAL MESSAGE:

  From: AndrewWatt2001@aol.com
  
  From: AndrewWatt2001@aol.com
  To: www-html-editor@w3.org
  Subject: CR XML Events - 2.1
  Date: Sun, 9 Mar 2003 15:28:08 EST
  Message-ID: <1c4.64e968d.2b9cfdd8@aol.com>
  X-Archived-At: http://www.w3.org/mid/1c4.64e968d.2b9cfdd8@aol.com
  
  In 2.1 reference is made to "an example root element". However only a start 
  tag is shown, and presumably it was intended to refer to a start tag only.
  
  Andrew Watt

REPLY 1:


  From: Shane McCarron <voyager-issues@mn.aptest.com>
  
  Thanks for your comment on xml-events.  We have made the change you suggested.

1.7 XML Events module implementations

PROBLEM ID: 6340

STATE: Feedback

NOTES:

  The implementations will be harmonized between the drafts, and will be stored in
  a consistent, non-date space location.

ORIGINAL MESSAGE:

  From: Masayasu Ishikawa <mimasa@w3.org>
  
  At the moment XML Events CR includes module implementations in DTD [1]
  and XML Schema [2].  XForms 1.0 used to duplicate XML Schema for XML
  Events, and at CR they oddly referred to a version in Member-only
  space [3].  Now we are going to include an another module implementation
  in RELAX NG in the next public draft of XHTML 2.0 [4].  Probably we
  should clear up this situation.
  
  As for XForms, hopefully we synchronize the PR publication so that
  XForms can refer to the latest version.  For XHTML 2.0, do we want
  to include the RELAX NG implementation in the XML Events spec itself?
  I personally don't object, although I fear someone might assert that
  it needs another CR period or we should go back to Last Call.
  
  In any case, I'd love to move module implementations out of the TR space.
  We have had enough trouble about that, and I don't want to repeat that.
  
  [1] http://www.w3.org/TR/2003/CR-xml-events-20030207/Overview.html#a_DTD_definition
  [2] http://www.w3.org/TR/2003/CR-xml-events-20030207/Overview.html#a_module_xml_events
  [3] http://www.w3.org/TR/2002/CR-xforms-20021112/sliceA.html#schema-events
  [4] http://www.w3.org/MarkUp/Group/2003/WD-xhtml2-20030428/relax_module_defs.html#a_rmodule_XML_Events
  
  Regards,
  -- 
  Masayasu Ishikawa / mimasa@w3.org
  W3C - World Wide Web Consortium