Re: xforms:copy binding query

Hi Aaron,

The TV example is a good one, but looking at it through the lens of how 
Erik and I are describing select, it would only be an argument that a UI 
control is the wrong thing to use to manage persisted data like favorite 
play lists.  Updating your favorites list is a data level operation that 
should ideally be done with actions to mutate the list and then possibly a 
local file submission to save the result.

As for select, there are basically two premises driving the conclusions 
here:
1) value and copy should do analagous things
2) value and copy are within a particular item, so they should have a 
localized effect, not a global effect on all items

It helps to start with copy, then apply the analogous ideas to value. 

If you have an item that is selected or deselected, we specify that this 
corresponds to insertion or deletion of the tree that matches the 
referenced node.  It doesn't make sense for copy to do an indeterminate 
number of insert or delete actions on trees that do not match its ref. The 
copy element is only there to determine whether or not a copy of the 
referenced tree should be in the content of the select's or select1's UI 
bound node.  In the case of a select1, the control deselects any selected 
item when some new item is selected.  But a select/select1 operates on 
content *using* its set of items, so if there is no item associated with 
the content, then the select/select1 has no way to select or deselect it. 

For copy, this method is played out using insert and delete actions on the 
data.  For value, the analogous operations have to occur on a 
space-separated string whose result is committed to the UI bound node by a 
setvalue.  This means that if one decides to change between a 
space-separated list and a list of elements, the selection control 
operates in fundamentally the same way (modulo changing between the type 
of mutation actions performed, which is an unavoidable result of changing 
the schema).

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





Aaron Reed <aaronr@us.ibm.com> 
Sent by: www-forms-request@w3.org
10/25/2007 10:15 AM

To
www-forms@w3.org
cc

Subject
Re: xforms:copy binding query







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
>