XForms 1.1 editor's draft updated

Yesterday I uploaded an update to 1.1 that addressed several outstanding 
action items of mine, and one additional issue that arose two days ago.

For all diffs, please see: 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html

The new inputmode content has been incorporated.
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#mode-scripts

The Common attribute now contains the note about including Events, and 
that Actions mention them for reading convenience because it actually 
makes the most sense to use them on the actual event handler elements.
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-attrs-common

The explicit mention of Events attributes on model has been removed, along 
with the confusing paragraph about why they might be available on the 
model element.
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-abstract
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model

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

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

Thanks,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw