Re: xforms:copy binding query

Hi Adam,

The group did previously resolve to add more text clarifying that copy and 
value are non-destructive.

They have always been non-destructive, so this is not a proposal for 
change, only clarification because enough implementers created destructive 
versions.

A version of the updated spec-ready text is available for review.  The 
working group will also review the spec-ready text; however, the 
diff-marked version[1] will show that there are no diff marks on the key 
issue here, which is that non-matching storage data results only in an out 
of range, not in any kind of destruction.

[1] 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-selectMany

Best regards,
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





Adam Retter <adam.retter@devon.gov.uk> 
Sent by: www-forms-request@w3.org
10/30/2007 03:38 AM

To
www-forms@w3.org
cc

Subject
Re: xforms:copy binding query







Hi chaps,

I have just digested and hopefully understood the discussion that you
have been having with my colleague Robert Walpole and his need for a
non-destructive xforms:copy.

I recently implemented xforms:copy in Chiba to the XForms 1.0
specification, and am considering now modifying it to provide the
functionality that Rob requires.

If I understand correctly - the proposal for XForms 1.1 is to change the
default behaviour of xforms:select and xforms:select1 from destructive
to non-destructive with appropriate range out-of-bound behaviour?

Now whilst we have a use case for this and it is indeed desirable, I am
slightly concerned that we are changing the default behaviour and that
this could effect many people. I think perhaps Aaron Reed is correct by
suggesting that the default behaviour should remain destructive and an
attribute @selection be added to allow for non-destructive behaviour.

I am looking to implement the recommendation this week if possible. Has
there been any further thought, on whether the default behaviour should
change or whether it should be configurable through an attribute?

Thanks

-- 
Adam Retter
Principal Developer
Devon Portal Project

County Hall
Topsham Road
Exeter
Devon
EX2 4QD

t: +44 (0)1392 38 3683
f: +44 (0)1392 38 2966
e: adam.retter@devon.gov.uk
http://www.devonline.gov.uk