RE: Problems with xf:copy and xf:delete

Aaron,

> Philip, please open a bug on our behavior and attach a testcase.

I can't do this until 23rd of February but I will attend to it as soon
as I can.


Regards and sorry for the delay in advance,

Philip Fennell



-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Aaron Reed
Sent: 11 February 2009 02:07
To: www-forms@w3.org
Subject: Re: Problems with xf:copy and xf:delete


I still say this is not consistent with the rest of the spec.  You are
saying that a select1 with a value WILL write over the all of the values
(text nodes) of the bound node but that a select1 with a xf:copy WON'T
write over all of the values (element nodes) in the bound node.  So a
select1 with a value CAN become 'in range' if extraneous values are
listed and if the user selects an item from the list but a select1 with
copy can NEVER become 'in range' if extraneous values are listed and if
the user selects an item from the list.  Leaving it, as far as I can
tell, the only type of single value, single bound control with this
behavior.  In my opinion it shouldn't matter what type of value is
getting selected, a select1 should always behave the same.  An XML
element inside a bound node can be left over, out of range junk just as
well as an out of range text node and there should be a means to get rid
of it w/o script.

I have less of a problem with xf:select behaving as you now describe
since it will be equally consistent whether the data values are text
nodes (xf:select using xf:value) or elements (xf:select using xf:copy)
and that in either case an 'out of range' value can never be brought 'in
range' (which I don't necessarily like, but it is a consistent logic
across the widget).

Philip, please open a bug on our behavior and attach a testcase. 
Hopefully someone will have time to get to it.

Thanks for listening,
--Aaron

Leigh L. Klotz, Jr. wrote:
> In
> http://lists.w3.org/Archives/Public/public-forms/2008Dec/0003.html
> I was assigned action Action 2008-12-3.2
> 
> * Problem with xf:copy and xf:delete
> http://lists.w3.org/Archives/Public/www-forms/2008Nov/0006.html
> - analyst needed
> 
> As Phulip Fennel points out, the spec here says:
> http://www.w3.org/TR/xforms11/#ui-selection-commonelems-copy
> 
> The target node, selected by the binding attributes on the list form 
> control, must be an element node...
> 
> The element node associated with the item, selected by the binding 
> attributes on copy, is deep copied as a child of the target node as if

> an insert action had occurred.
> 
> For de-select it says:
> The child element node associated with the item, selected by the 
> binding attributes on copy, is deleted as if a delete action had
occurred.
> 
> Philip Fennell seemed to think existing content would be left alone, 
> and only the contributions of the select itself altered.  Aaron Reed 
> has implemented the notion that the select controls the entire 
> contents of the target node.
> 
> The WG consensus is that Philip is correct; the document text was 
> specifically written to make sure that select leaves alone any
existing
> content.   select/itemset/value should so the same as well, so if
Mozilla
> XForms doesn't do that, it also should.
> 
> Leigh.
> 
> 
> 




http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Friday, 13 February 2009 15:20:38 UTC