Non-applicability of readonly to group, etc.

There were 315 occurrences of the term form control, and quite a bit of 
inconsistency in the use of the term.  So, there were bound to be some 
places where the choices I made to resolve the conflicts did not match 
everyone's expectations.  Certainly we can make changes as needed. 

The main case that appears to have come up is the seeming 
non-applicability of readonly to group.

The crux of the problem is that Section 8 defined "form control" to be the 
only the controls defined in Section 8, i.e. only the "core" form controls 
and not the containers.  But Section 4 said that form control is those 
core form controls plus group.  Yet if you look at every event in Section 
4, you can see that both definitions are wrong.

Prior to the update, we have (since 1.0 first edition in fact) defined a 
behavior for setting the focus to a repeat, so clearly it's not just 
group.  Moreover, switch also has a ref, and both group and switch are 
subject to model relevancy, so again clearly it's not just core controls 
plus group.

This is just a mess, and I took the responsibility to clean it up.  The 
rule I used was to stop trying to cling to specific words in the spec that 
were convenient, but rather to assume that ALL definitions of form control 
were slightly out of whack and then fix the whole thing according to other 
features that are actually present.

This is why the xforms-readonly and xforms-readwrite events do not list 
"group" and "switch" as targets.  I assumed that the definition of form 
control in Section 4 was wrong (in this case because it excluded switch, 
for one), and I further assumed that it was slightly wrong on a case by 
case (event by event) basis.

So, notice that group and switch are included in xforms-enabled and 
xforms-disabled.  This is because we document the feature that the 
relevant MIP applies to group and switch.  We say that a group or switch 
*does something* when the node to which it is bound becomes non-relevant. 
Since xforms-enabled and xforms-disabled are related to relevance, clearly 
they *should* be dispatched to group and switch.  But a group or switch 
*does nothing* with the readonly MIP, the constraint/type/schema validity 
information, so as the starting position I assumed that these events are 
*not* dispatched to group and switch.

If they are supposed to be dispatched to group, then they should also be 
dispatched to switch.  But I don't really like this idea of dispatching 
events that have no meaning to a control.  In the long run, it seems like 
controls will have to tell the model which events they are interested in 
receiving once we get to custom controls, but for controls that we know 
about, setting reasonable defaults seems like a good idea.  If we do 
decide to dispatch events like xforms-readonly to a group, then this 
*will* imply to some people that a group (or switch) can be made readonly. 
 Does that mean you cannot change the switch case?  We didn't specify 
that.  Does that mean that the controls within it must behave as if they 
are readonly (like relevance)?  We didn't specify that either.

In order to properly process what happened to events, please look at the 
Events overview table in Section 4 (
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#rpm-events) 
and everywhere you see "Core Form Controls" with nothing else, remember 
that it used to say "form controls" and that included group but not 
switch.  Everywhere it says "Core Form Controls" plus group, switch and/or 
repeat, remember that that also used to say just group.  Then ask yourself 
if either the elimination of group or the addition of switch and/or repeat 
is appropriate.  Because the section was just wrong in the past.

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
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