- From: Ulrich Nicolas Lissé <unl@dreamlab.net>
- Date: Tue, 08 May 2007 09:57:13 +0200
- To: ebruchez@orbeon.com
- CC: public-forms@w3.org
Erik, Erik Bruchez wrote: > <snip/> > > Mmm... Maybe I read between the lines, maybe not. Here is the text I > am referring to: > > "When a group becomes non-relevant, it must receive event > xforms-disabled and then the XForms action handlers that are > listening for events on the non-relevant group must be > disabled. When a non-relevant group changes to being relevant, the > XForms action handlers that listen for events on the group must > become enabled and then the group must receive the event > xforms-enabled." > > It seems that this does not preclude an implementation to send other > MIPs to the group. However, it is not very clear whether it MUST send > other MIP events. Consider section "4.3.4 The xforms-refresh Event", > which dictates how MIP events are dispatched: > > "4. For each *form control* [...]" (emphasis mine) > > Is xforms:group an XForms control? Not according to the categorization > of the table of contents! Which seems to indicate that the spec does > not mandate that MIP events other than xforms-enabled/xforms-disabled > be dispatched to xforms:group, bound or not. Nor does it explicitly > preclude it, but that's guesswork then. > > Does anybody see more on this topic in the spec? in section "4.1 Events Overview" [1] the second paragraph reads: Throughout this chapter, each reference to "form control" as a target element is a shorthand for any of the following elements: input, secret, textarea, output, upload, trigger, range, submit, select, select1, or *group*. Regards, Uli. [1] http://www.w3.org/TR/xforms/index-all.html#rpm-events -- Ulrich Nicolas Lissé
Received on Tuesday, 8 May 2007 07:57:21 UTC