W3C home > Mailing lists > Public > www-forms@w3.org > February 2009

Problems with xf:copy and xf:delete

From: Leigh L. Klotz, Jr. <Leigh.Klotz@xerox.com>
Date: Tue, 10 Feb 2009 17:08:46 -0800 (PST)
Message-ID: <4581897e122c5690642b3d26eb3146c1.squirrel@graflex.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:15 GMT