Re: CDR: Event-related markup

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: CDR: Event-related markup

Charles McCathieNevile-2

Maciej, you wrote

> "2.2.3 Event-Related Legacy Markup"
>
> - I object to the use fo the word "legacy". Event-related markup is in  
> the current versions of many specifications and is not deprecated.

The group agrees and will remove the word Legacy.

> "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?

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

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

For the CDF working group, Cheers

Chaals

--
Charles McCathieNevile                     [hidden email]
   hablo español  -  je parle français  -  jeg lærer norsk
      Peek into the kitchen: http://snapshot.opera.com/

Reply | Threaded
Open this post in threaded view
|

Re: CDR: Event-related markup

Maciej Stachowiak


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


Reply | Threaded
Open this post in threaded view
|

Re: CDR: Event-related markup

Bjoern Hoehrmann

* Maciej Stachowiak wrote:
>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.

Note that some XML Events implementations allow all sorts of "handlers",
Opera for example supports the <script> element as handler in XHTML
documents, XHTML+Voice 1.2 uses vxml:form elements as handlers, and
XForms does similar things if I remember correctly.

>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.

Note that there is no XML Events Working Group. The HTML Working Group
was chartered to maintain XML Events, but the charter expired long ago
in 2004 as you can read on http://www.w3.org/MarkUp/Activity so there
wasn't and isn't any maintenance of the Recommendation. Which is quite
a problem, I recently implemented XML Events plus the modifications
defined in SVG Tiny 1.2 and most of it did not make much sense at all,
XML Events alone even less.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: CDR: Event-related markup

Maciej Stachowiak


On Jan 30, 2006, at 10:28 PM, Bjoern Hoehrmann wrote:

>> 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.
>
> Note that there is no XML Events Working Group. The HTML Working Group
> was chartered to maintain XML Events, but the charter expired long ago
> in 2004 as you can read on http://www.w3.org/MarkUp/Activity so there
> wasn't and isn't any maintenance of the Recommendation. Which is quite
> a problem, I recently implemented XML Events plus the modifications
> defined in SVG Tiny 1.2 and most of it did not make much sense at all,
> XML Events alone even less.

In that case it seems like a major problem for any other spec to  
depend on XML Events.

Regards,
Maciej


Reply | Threaded
Open this post in threaded view
|

Re: CDR: Event-related markup

Bjoern Hoehrmann

* Maciej Stachowiak wrote:

>> Note that there is no XML Events Working Group. The HTML Working Group
>> was chartered to maintain XML Events, but the charter expired long ago
>> in 2004 as you can read on http://www.w3.org/MarkUp/Activity so there
>> wasn't and isn't any maintenance of the Recommendation. Which is quite
>> a problem, I recently implemented XML Events plus the modifications
>> defined in SVG Tiny 1.2 and most of it did not make much sense at all,
>> XML Events alone even less.
>
>In that case it seems like a major problem for any other spec to  
>depend on XML Events.

Yes, I'm very worried about the SVG Working Group's decision to somehow
adopt vanilla XML Events, just like I was and still am worried about the
http://www.w3.org/mid/42b4d54f.193020078@... new
similar but different <handler> elements, XHTML 2.0 has one, XBL2 has
another, sXBL has its own, then SVG 1.2 joins the club, and so on. It's
a pity but it seems it's less work to reinvent this for each format
rather than to invent it just once.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

RE: CDR: Event-related markup

Jon Ferraiolo

Bjoern,
Very minor correction - sXBL does not define its own handler element. It inherits script and handler elements from its host language.

sXBL does define an sxbl:handlerGroup element, but this is to allow a component developer to create event handler "templates" which cause the enclosed event handlers to be attached to each instance of a component. With sXBL, the contents of sxbl:handlerGroup are event handlers from the host language, such as svg:handler.

It looks as if the Mozilla XBL2 spec has something similar to sxbl:handerGroup with xbl2:handlers (http://www.mozilla.org/projects/xbl/xbl2.html#handlers0), but Mozilla XBL2 also defines its own xbl2:handler element (http://www.mozilla.org/projects/xbl/xbl2.html#the-handler). My guess is that Ian&friends recognized that it makes sense to have a handler element that is different than html:script and that it is easier to add a handler element to the XBL2 spec (and sell XBL2 to the W3C) than the more general-purpose approaches of adding a handler element to XHTML or adding a handler element to XML Events (and thereby making XML Events a prerequisite for XBL2). Given progress on CDF/WICD, I expect that XML Events will get universalized in the not-too-distant future such that it works across both XHTML and SVG within the context of WICD, in which case my vote would be to add a handler element to XML Events rather than the future W3C XBL spec.

Jon


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Bjoern Hoehrmann
Sent: Monday, January 30, 2006 11:30 PM
To: Maciej Stachowiak
Cc: Charles McCathieNevile; [hidden email]
Subject: Re: CDR: Event-related markup


* Maciej Stachowiak wrote:

>> Note that there is no XML Events Working Group. The HTML Working Group
>> was chartered to maintain XML Events, but the charter expired long ago
>> in 2004 as you can read on http://www.w3.org/MarkUp/Activity so there
>> wasn't and isn't any maintenance of the Recommendation. Which is quite
>> a problem, I recently implemented XML Events plus the modifications
>> defined in SVG Tiny 1.2 and most of it did not make much sense at all,
>> XML Events alone even less.
>
>In that case it seems like a major problem for any other spec to  
>depend on XML Events.

Yes, I'm very worried about the SVG Working Group's decision to somehow
adopt vanilla XML Events, just like I was and still am worried about the
http://www.w3.org/mid/42b4d54f.193020078@... new
similar but different <handler> elements, XHTML 2.0 has one, XBL2 has
another, sXBL has its own, then SVG 1.2 joins the club, and so on. It's
a pity but it seems it's less work to reinvent this for each format
rather than to invent it just once.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 


Reply | Threaded
Open this post in threaded view
|

RE: CDR: Event-related markup

Ian Hickson

On Tue, 31 Jan 2006, Jon Ferraiolo wrote:
>
> It looks as if the Mozilla XBL2 spec has something similar to
> sxbl:handerGroup with xbl2:handlers, but Mozilla XBL2 also defines its
> own xbl2:handler element. My guess is that Ian&friends recognized that
> it makes sense to have a handler element that is different than
> html:script and that it is easier to add a handler element to the XBL2
> spec (and sell XBL2 to the W3C) than the more general-purpose approaches
> of adding a handler element to XHTML or adding a handler element to XML
> Events (and thereby making XML Events a prerequisite for XBL2).

Actually XBL2 here is merely keeping XBL1's <handlers> and <handler>
elements -- no elements were added. The reason is that it's easier for
authors. There was no thought put to using elements from other namespaces
because that would have made it harder for authors, and there was no
thought put to making it more palatable for the W3C -- authors are all
that really matters here.

Using XML Events here would _definitely_ not have made sense because XML
Events is so woefully underdefined as to be essentially useless.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'