RE: [SVGMobile12] namespace events are not qualified?

Mark,
My analysis is the same as yours that if we were starting off from scratch 
it would be better to change DOM3 Events, but I am not sure about whether 
the rest of the world would agree with this, particularly the DOM WG, who 
took the current specification through the Last Call process already. 
Certainly, it makes sense for the SVG WG (which I believe owns the DOM3 
Events spec at this point, although that might just be temporary) to 
coordinate with the leadership of the DOM WG (particularly Philippe) about 
this issue. If the leadership agrees that such a specification change is 
needed, then DOM3 Events would need to go through Last Call again after 
this change was made.

Jon

At 05:18 AM 5/25/2005, Mark Birbeck wrote:
>HI Jon,
>
>My suggested resolution though, is to change DOM 3 Events. I would say 
>that it is completely unworkable as it stands, not just for SVG but for 
>any application that makes use of both DOM 2 and DOM 3 Events.
>
>The main problem from a backwards compatibility problem is that I cannot 
>generate an event "xyz:abc" safe in the knowledge that only listeners who 
>*really* want that event will be triggered. I cannot be sure that I won't 
>also trigger listeners for "abc", who have never even heard of DOM 3 
>Events, or the set of events that sit in the namespace "xyz".
>
>Regards,
>
>Mark
>
>
>Mark Birbeck
>CEO
>x-port.net Ltd.
>
>e: Mark.Birbeck@x-port.net
>t: +44 (0) 20 7689 9232
>w: <http://www.formsplayer.com/>http://www.formsPlayer.com/
>b: <http://internet-apps.blogspot.com/>http://internet-apps.blogspot.com/
>
>Download our XForms processor from
><http://www.formsplayer.com/>http://www.formsPlayer.com/
>
>
>
>----------
>From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of 
>Jon Ferraiolo
>Sent: 25 May 2005 01:07
>To: Mark Birbeck
>Cc: 'KONO Masahiko'; www-svg@w3.org
>Subject: RE: [SVGMobile12] namespace events are not qualified?
>
>Mark,
>[As usual!] You are absolutely correct in your analysis. Thanks for 
>carefully describing this whole process and how events are now promiscuous 
>(i.e., DOM2Events "click" really means DOM3Events {"*", "click"}). I 
>suggest that the SVG-t 1.2 spec (and also the SVG-Full 1.2 spec) highlight 
>this somehow to make sure implementers and developers don't get confused 
>(as I was).
>
>Also, I think there needs to be some spec changes in section 13.2 
>[http://www.w3.org/TR/SVGMobile12/interact.html#SVGEvents]. For example, 
>the SVG-t 1.2 spec says:
>
>--------------------------------------
>SVG 1.1 names are all assumed to be in the 
>"http://www.w3.org/2001/xml-events" namespace. This allows SVG 1.1 content 
>(which did not have a notion of namespaced events) to be upwardly 
>compatible with SVG 1.2 (which adds a notion of namespaced events). 
>Therefore, the SVG 1.1 "SVGZoom" event becomes the 
>{"http://www.w3.org/2001/xml-events", "SVGZoom"} event in SVG 1.2.
>--------------------------------------
>
>Based on the promiscuity statements about backwards compatibility with 
>DOM2 Events, I believe the above bullet is wrong. The old "SVGZoom" is 
>really {"*", "SVGZoom"}.
>
>Jon
>
>At 05:26 PM 5/19/2005, Mark Birbeck wrote:
>>Hi Jon,
>>
>> > Very important issue here.
>>
>>Definitely.
>>
>>
>> >  Thanks for initiating discussion.
>>
>>Thanks for replying so quickly ;)
>>
>>
>>I said:
>> > >             Let's say we register for:
>> > >
>> > >                * click
>> > >                * ev:click
>> > >                * myns:click
>> > >                * yourns:click
>> > >
>> > >
>> > >             1. If we dispatch the old DOM 2 Event "click", *all* of
>>these listeners
>> > >                will be triggered.
>>
>>You replied:
>> >       Assuming the ev: is assigned to the XML Events namespace and myns:
>>and yourns:
>> > are assigned to different namespaces, then, no, if the mouse is clicked,
>>then only
>> > the event listeners for "click" and "ev:click" would receive the event.
>>At least
>> > that is my thinking based on studying the DOM3 Events spec which appears
>>to retroactively
>> > claim that HTML's click event when namespaced becomes ev:click.
>>
>>No, I'm pretty certain that this is not what happens. As you rightly say,
>>the implication of the DOM 3 Events spec is that there is no longer a
>>"click" event, but there is now a {"http://www.w3.org/2001/xml-events",
>>"click"} event. So far so good.
>>
>>However, it also says that if the *listener* is registered for an event with
>>no namespace (e.g., "click") OR the event generated has no namespace (e.g.,
>>{null, "click"}), then the types will match, *regardless* of the namespace
>>[1]:
>>
>>    For compatibility reasons, the dispatching of an event will ignore
>>namespace URIs
>>    if either the event or the event listener has a null namespace URI.
>>
>>The Note goes on to describe what this means:
>>
>>    If a DOM Level 2 event (i.e. with a null namespace URI) is dispatched in
>>the DOM
>>    tree, all event listeners that match the type will be triggered as
>>described in
>>    the DOM event flow.
>>
>>So, say I give you an XBL document to use with your documents, and my
>>document is written to use DOM 2 Events. If it dispatches good old-fashioned
>>"click", *all* of the following DOM 3 Event listeners will be triggered in
>>your document:
>>
>>    * ev:click
>>    * myns:click
>>    * yourns:click
>>
>>as well as any DOM 2 Event listeners waiting for "click". Note that this
>>means that it's not enough for you to avoid using type names from the list
>>of 'core' events -- the problem is caused by any DOM 2 Event.
>>
>>So, just so that everything is clear, if you don't mind me
>>cutting-and-pasting your words, I would say that when you say this:
>>
>>   ...if the mouse is clicked, then only the event listeners for "click" and
>>   "ev:click" would receive the event...
>>
>>although it's what we would like, the reality is you can't say "only":
>>
>>   ...if the mouse is clicked, then the event listeners for "click" and
>>   "ev:click" would receive the event, as would any other listener with
>>   "*:click"...
>>
>>
>>Next the Note says this:
>>
>>    If a DOM Level 3 event (i.e. with a namespace URI) is dispatched in the
>>DOM tree,
>>    all event listeners with the same type and the same or null namespace URI
>>will be
>>    triggered as described in the DOM event flow.
>>
>>The consequence of this is that if my XBL object is 'listening' for "click"
>>to come from your document, any handlers that I have registered will be
>>invoked if my code receives *any* of the following events from your
>>document:
>>
>>    * ev:click
>>    * myns:click
>>    * yourns:click
>>
>>as well as the DOM 2 Event "click".
>>
>>In other words we have {"*", "click"}, if you'll forgive my notation.
>>
>>
>> >       What I am assuming is that an implementation would create a DOM3
>>Event object
>> > for all events, whether the event listener uses DOM2 or DOM3 methods. For
>>"click"
>> > events, the namespaceURI value on the Event object would be set to
>> > "http://www.w3.org/2001/xml-events".
>>
>>In DOM 3 Events-compliant code it would, since you would use initEventNS().
>>But sticking with my example, my DOM 2 Event-compliant code will call
>>initEvent() on this Event object, thus setting the namespace URI to null. If
>>I then call dispatchEvent() on some target node, it would of course
>>correctly trigger any listener for "click". But as I've said, it would also
>>trigger any other listeners with a type of "click", even if they have
>>non-null namespaces.
>>
>>And further, I'm saying that the "click" listener that you set up to listen
>>for this "click" event would also be triggered by an event that was
>>initialised with initEventNS() and dispatched as {"myns", "click"}.
>>
>>To put all of this a different way, it is only fully qualified event names
>>(i.e., QNames) that are 100% unambiguous. Any use of unqualified names is
>>ambiguous.
>>
>>[snip]
>>
>>
>> >       Actually, I think it all works nicely if "click" is truly
>>equivalenced to
>> > "ev:click", meaning that the assumed default namespace for legacy HTML and
>>SVG
>> > events is "ev:".
>>
>>But as I've tried to show, this is actually not possible to achieve -- there
>>is no way I can see in the DOM Events model to make this kind of
>>'equivalence' (unless the core events are in no namespace in both DOM 2
>>Events and DOM 3 Events).
>>
>>
>> > I believe that attempting to wildcard "click" to mean everything:click is
>>what
>> > would cause problems.
>>
>>Exactly!
>>
>>
>>I have to say, I cannot see how it is possible to say that "click" ==
>>"ev:click" if you are allowing DOM 2 Events and DOM 3 Events to co-exist.
>>The whole "ignore namespaces" thing is an attempt to solve this problem, but
>>as far as I can see it just doesn't work.
>>
>>(I think there are other problems with DOM 3 Events, but I'll leave those
>>for a separate thread.)
>>
>>Regards,
>>
>>Mark
>>
>>[1]
>>http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-dom2-compatibilit
>>y
>>
>>
>>Mark Birbeck
>>CEO
>>x-port.net Ltd.
>>
>>e: Mark.Birbeck@x-port.net
>>t: +44 (0) 20 7689 9232
>>w: http://www.formsPlayer.com/
>>b: http://internet-apps.blogspot.com/
>>
>>Download our XForms processor from
>>http://www.formsPlayer.com/