Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document outlines the way in which the HTML Working Group addressed the comments submitted during the XML Events Candidate Recommendation review period.
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.
| Issue | State | Resolution |
|---|---|---|
| 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. |
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
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.
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
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?
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/
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.
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