Re: XForms 1.1 editor's draft updated

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

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.

Good clarification!


Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Received on Sunday, 19 October 2008 20:24:44 UTC