W3C home > Mailing lists > Public > public-cdf@w3.org > January 2006

Re: CDR: Event-related markup

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 30 Jan 2006 22:16:14 -0800
Message-Id: <04D85E05-011C-45CC-B35E-AC4DB78CE545@apple.com>
Cc: public-cdf@w3.org
To: Charles McCathieNevile <chaals@opera.com>


On Jan 29, 2006, at 4:29 PM, Charles McCathieNevile wrote:

>> "In order to claim conformance to this Compound Documents  
>> Framework, a compound document profile must define how all of its  
>> event-related language constructs and scripting constructs map to  
>> corresponding DOM3 event facilities, unless DOM3 events has  
>> already defined the mapping."
>>
>> - SVG Tiny 1.2 does not fully define this relationship; neither  
>> does XML events. I request that the CDF working group coordinate  
>> on this issue with other relevant working groups.
>
> The working group agrees. Would you be kind enough to list the gaps  
> you see in the current definitions for XML events with respect to  
> DOM 3, to ensure that we catch them all?

XML Events does not define anything in terms of equivalent DOM  
interfaces and method calls. Is adding a <listener> element  
equivalent to some DOM EventTarget interface? How about removing it?  
What about adding/removing elements that directly have XML events  
attributes on them? This may be difficult since XML Events does not  
specify the form of handler elements, but surely it could specify in  
some vague way that handler events create an instance of the  
EventListener interface and then specify the semantics of how these  
are attached to or removed from the node.

> As you may be aware, SVG Tiny 1.2 has removed previous extensions  
> to XML events.

They have indeed declared their intent to remove incompatible  
extentions. But I do not expect them to remove the <handler> element,  
since without it, the provided XML Events support is useless (unless  
they remove XML Events entirely, which I've also proposed). The last  
released draft also has some partial specifications of how <handler>  
elements (and standard XML Events elements) are equivalent to DOM  
Events calls, but these do not cover all cases.

Furthermore, SVGT 1.2 in the latest draft defines an event model that  
is incompatible with both DOM Events and XML Events, since it lacks a  
capture phase.

> I hope that this resolves your concern. If not, please let the  
> working group know within two weeks.

Does your message mean that you will coordinate with both the XML  
Events and SVG working groups on this? I couldn't tell. It sounded  
like you may have been saying that no coordination with SVG is  
necessary but I do not think that is the case. Please clarify and I  
will let you know if this resolves my concern.

Regards,
Maciej
Received on Tuesday, 31 January 2006 06:17:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:40 GMT