W3C home > Mailing lists > Public > www-forms@w3.org > October 2007

Re: xforms:copy binding query

From: Aaron Reed <aaronr@us.ibm.com>
Date: Thu, 25 Oct 2007 12:15:57 -0500
To: www-forms@w3.org
Message-ID: <ffqj36$hhd$1@ger.gmane.org>

Hi Erik,

 >> I may be using a remembered instance document that has values that
 >> no longer applies to the business process that I'm trying to modify.
 >> For example, inventory flavors or styles that are no longer
 >> available -> there will be no way to get rid of them.

 >Well you can also use actions to clear or adjust the values.

 >One could argue that document migration is a valid use case, but in
 >general such migration is likely to entail much more than changing
 >values in selects and you may have to resort to something like an XSLT
 >transform to migrate your documents anyway.

Ok forget an inventory example.  Lets think about a TV.  With many TVs, 
you can configure a 'favorites list'...a small list of favorite channels 
that you can flip through quickly before going to a larger list.  So I 
buy a TV and I set this up.  2 years down the road I decide I don't have 
time to watch enough sports to spend an extra $10 a month for that 
package.  So the cable guys remove the channels and I re-run the setup 
feature on the TV so that it resets the channels that my TV will flip 
through.  But the favorites list doesn't change.  If they are using a 
XForms select and allowing me to only select from channels that my TV 
gets, any sports channels that were in my favorites list and I can't get 
rid of because they aren't in the list of channels that my TV recieves 
so I can't deselect them.  You can see in this case the data (the 
channels I recieve) and the client device (the TV) are managed by 
individual entities so there is no migration solution.  And if I had 
dead channels hogging up my favorites list without a way to fix it, I 
would be cursing my TV as a piece of cr*p.


 >> I assume that authors and users have found that 99% of the time this
 >> is just dandy.

 >That sounds like a, uh, wild assumption to me ;-)

Count up the number of notes to the working group that wanted a behavior 
like this versus the hundreds or thousands of forms that were 
successfully written without this behavior.  And that's just XForms. 
HTML selects also only submit what is selected.  99% is being 
conservative. :)

 >> I guess ignorance is bliss because the poor visually impaired user
 >> with an accessible processor will probably have the value echoed
 >> back to him and will be wondering how that value even got in there
 >> and how the heck to get rid of it.  Just seems wrong to me.

 >Well, one could argue that the validity of the document should be
 >handled via a bind constraint or schema definition, not by assuming the
 >control sets the right value. You will have the same problem with an
 >out of range xforms:range.

But I'm not talking about validity.  I'm talking about data being placed 
in the bound node that is not represented by the control.  An out of 
range node bound to a xf:range can be brought into range by using the 
control.  So even if the user is confused, it can be quickly corrected. 
  The value set by the xf:range when it sets its value is actually 
represented by the control.

Of course most of your points are valid.  I'm not trying to say that 
select shouldn't be able to behave as you guys wish and that it must 
conform to the behavior of the other controls.  I think that the use 
case in this thread is perfectly valid.  I am saying that the DEFAULT 
behavior should be consistent with the other controls and that a few use 
cases like this isn't worth changing the DEFAULT behavior.  Select could 
still easily handle this use case and others like it by adding a flag to 
the selection attribute or a whole different attribute can be added.

--Aaron

Erik Bruchez wrote:
> 
>  > Man, I don't like this either for the same reason Nick gave...there
>  > is no way for the select to become 'in range' once it is out of
>  > range without another control intervening.
> 
>  > I may be using a remembered instance document that has values that
>  > no longer applies to the business process that I'm trying to modify.
>  > For example, inventory flavors or styles that are no longer
>  > available -> there will be no way to get rid of them.
> 
> Well you can also use actions to clear or adjust the values.
> 
> One could argue that document migration is a valid use case, but in
> general such migration is likely to entail much more than changing
> values in selects and you may have to resort to something like an XSLT
> transform to migrate your documents anyway.
> 
> So I understand your point, but there are use cases for the
> destructive approach as well as the non-destructive approach. At some
> point we have to make a decision, and so far the WG thinks that there
> are not many disadvantages to follow the non-destructive approach.
> 
> At least by going the non-destructive way, you leave open the door to
> handling the destructive use cases, albeit with a little more work,
> while if you go the other way around, you can't: the control will
> destroy your data, and you can't implement use cases such as having
> multiple selection controls bound to the same node. For example, a use
> case given recently:
> 
>   <xforms:select ref="my-data" appearance="full">
>     <xforms:label/>
>     <xforms:item>
>       <xforms:label>Blue</xforms:label>
>       <xforms:value>blue</xforms:value>
>     </xforms:item>
>   </xforms:select>
> 
>   and somewhere else in the page:
> 
>   <xforms:select ref="my-data" appearance="full">
>     <xforms:label/>
>     <xforms:item>
>       <xforms:label>Red</xforms:label>
>       <xforms:value>red</xforms:value>
>     </xforms:item>
>   </xforms:select>
> 
>  > If this new rule truly applies only to xf:select and not to the
>  > other controls, then that means that we feel that the destructive
>  > behavior as a default is a fine and desirable behavior in EVERY
>  > circumstance other than when xf:select is used.
> 
> I can't see how other controls cannot be destructive. xforms:select is
> the only control dealing with lists of values, which makes being
> non-destructive a possible behavior for this control only.
> 
>  > I assume that authors and users have found that 99% of the time this
>  > is just dandy.
> 
> That sounds like a, uh, wild assumption to me ;-)
> 
>  > But in this case it is a control setting a value that it can't even
>  > accurately represent.
> 
> XForms had since the beginning the notion that a control could be out
> of range. xforms:range is the best example, but xforms:select had this
> feature since the beginning as well.
> 
> Also, XForms has a quite strong separation between the data model and
> the controls, and this separation has even increased in XForms 1.1,
> witness the work done to separate xforms:insert/xforms:delete from
> xforms:repeat, for example. So it is probably not unacceptable to
> think that there can be a disconnect between data in the data model
> and what controls can show.
> 
>  > The value being submitted to the server, if there is no other
>  > control bound to that node, will be a value that the user has no way
>  > to know it is even there.
> 
>  > I guess ignorance is bliss because the poor visually impaired user
>  > with an accessible processor will probably have the value echoed
>  > back to him and will be wondering how that value even got in there
>  > and how the heck to get rid of it.  Just seems wrong to me.
> 
> Well, one could argue that the validity of the document should be
> handled via a bind constraint or schema definition, not by assuming the
> control sets the right value. You will have the same problem with an
> out of range xforms:range.
> 
> And you can tell the user, since the control is supposed to indicate
> the out of range condition.
> 
>  > As John pointed out, there is nothing in the spec that precludes a
>  > control from doing this.  So if this change actually comes to
>  > fruition, I hope the new wording will clearly define when an author
>  > can expect destructive behavior and when he can't.
> 
> It sure will ;-)
> 
> (The above is just my opinion, not that of the Forms Working Group.)
> 
> -Erik
> 
Received on Thursday, 25 October 2007 17:37:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:11 GMT