Re: Non-applicability of readonly to group, etc.

John, All,

First of all I want to say that the spec is more clear after the 'form 
control/core form control' changes you made. But I'm a bit worried about 
removing group as a target of certain MIP events because it was in 
previous versions clearly stated in the spec that group was a valid 
target. And someone could have written a form that was based on this. So 
changing this after last call, without a specific last call comments (or 
maybe there is one, but I can't recall one), gives me a bit the creeps. 
But I just wanted to point this out to the group, and thought that it was 
maybe left out by accident.

To recap, it is my first transition from WD to LC to PREC, so maybe I'm 
thinking a bit to black&white, but isn't this change (group is no longer a 
valid target for certain events) a big change to make after LC? On the 
other hand this change will not break any forms currently generated by the 
designer of my company, so if no one else can come up with good use cases 
and there is consensus for removing group as a valid target, I won't be 
the one to block this change. 

Regards,

Nick Van den Bleeken  -  Research & Development
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com


public-forms-request@w3.org wrote on 09/05/2007 08:11:56 AM:

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




--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer

Received on Wednesday, 5 September 2007 08:01:50 UTC