Re: xforms:copy binding query

Hey John,

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

So now you are saying that select1 also won't wipe out previous values?

As I've said before, I get why we want to support this.  I do NOT get 
why we would throw away years of consistent, cross-control default 
behavior when we don't have to.  We can do both.  Allowing a couple of 
controls to set values that they can't possibly represent is not good 
DEFAULT behavior.  Good DEFAULT behavior keeps us in line with 
traditional web form behavior.

--Aaron

John Boyer wrote:
> 
> 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
>  >
> 
> 
> 
>

Received on Friday, 26 October 2007 17:51:02 UTC