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

I was assigned action Action 2008-12-3.2

* Problem with xf:copy and xf:delete
- analyst needed

As Phulip Fennel points out, the spec here says:

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.

Received on Wednesday, 11 February 2009 01:09:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:22 UTC