Re: xforms:copy binding query

Hi Aaron,

No, I didn't say that select1 doesn't delete old values.  I only said that 
select and select1 operate through their items.

A select1 deselects the old item (so the copy in the old item does a 
delete), and then it selects the new item (so the copy in the new item 
does an insert). [1, 2]

[1] 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#rpm-event-seq-swovc
[2] 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-selection-commonelems-copy

Granted a strict reading of [1] applies to the basis case of select1.  It 
should be tweaked a bit to allow for zero deselects (for a select control) 
or possibly multiple deselects if a select1 is bound to an out of range 
node (i.e. a node having multiple items selected).

Still, for the question you asked about whether select1 should delete the 
old setting when copy is used, it's clear from [1,2] the answer is 
absolutely yes.

It is less clear but I would agree with you true that it should even do so 
if multiple things are selected.  The control is out of range, but when 
the user actually selects something, a select1 should choose that thing to 
the exclusion of all its other items.

But note that the select1 may remain out of range after the selection if 
it did not have items that were bound by copy matching to nodes in the 
node referenced by the select1.

It's not that this is 'default' behavior either.  This is just what 
happens when you feed out of range data to the select1; it is even 
supposed to get an out of range event [3] (a little later, after the 
refreshment that accompanies the actual value change [4]).

[3] 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-out-of-range
[4] 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-refresh

Cheers,
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/26/2007 10:28 AM

To
www-forms@w3.org
cc

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