- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Sun, 19 Oct 2008 13:24:04 -0700
- To: Forms WG <public-forms@w3.org>
> It has been noted in xforms-insert and xforms-delete that although > they are notification events in the sense that they have no default > processing from the vantage point of the insertion and deletion > processing models, the repeat processor does attach behavior to the > capture phase of the event. This was the actual issue raised by > Erik. We talked about solving the issue by removing all language > about "notification" events from the spec. However, this is more of > a surgery (spec reorganization) than perhaps we anticipated, not a > simple iteration of a removal process. I think this reorganization > work will naturally occur during the modularization refactoring in > 1.2, so I'd recommend that we go with the more direct and less > invasive fix for now. > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-insert > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-delete That simple solution works as far as I am concerned. > The description of the effect of the relevant property on the UI has > been edited to avoid a possible misinterpretation that was recently > brought to my attention. Two clarifications occurred. The > application of relevance to an element was explicitly associated > with *single-node* *UI bindings*. There was a sentence which > attempted to clarify that direct non-availability of an element due > to non-relevance was not an effect applied to action elements, but > this was getting confused with the language in Chapter 8 that says > actions attached to non-relevant form controls are disabled. > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-prop-relevant Good clarification! -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
Received on Sunday, 19 October 2008 20:24:44 UTC