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/