- From: Leigh L. Klotz, Jr. <Leigh.Klotz@xerox.com>
- Date: Tue, 10 Feb 2009 17:08:46 -0800 (PST)
- To: public-forms@lists.w3.org
- Cc: Philip.Fennell@bbc.co.uk, dev-tech-xforms@lists.mozilla.org, www-forms@w3.org, aaronr@us.ibm.com, leigh.klotz@xeorx.com
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.
Received on Wednesday, 11 February 2009 01:09:24 UTC