W3C home > Mailing lists > Public > www-forms-editor@w3.org > September 2007

Re: LC: Clarify expectation of deleted-nodes property of xforms-delete (PR#18)

From: John Boyer <xforms-issues@mn.aptest.com>
Date: Tue, 11 Sep 2007 04:37:18 -0500
Message-Id: <200709110937.l8B9bItV031685@htmlwg.mn.aptest.com>
To: boyerj@ca.ibm.com
CC: www-forms-editor@w3.org

It was necessary to remove this notion of half-detached nodes.  Although it
would be nice to be able to determine the parents of deleted nodes so that
behaviors can be taken based on the exact nodes deleted, but there is no
reasonable way to do this that always works.  Moreover, for the cases that work
via this method, the same cases already work with other event information.

John Boyer

> In Section 4.4.6, the xforms-delete event is discussed.
> 
> The deleted-nodes property states that the deleted "nodes are no longer
> referenced by their parents."  It is strongly implied but not stated that
> the detachment is only one way, i.e. that the nodes still reference their
> parents.
> 
> It should be clarified that it is possible to traverse upward to the
> former ancestors of the deleted nodes.
> 
> This should also be normatively stated in the section on the delete action
> (Section 9.3.6, bullet point 4).  Currently that text simply says the
> nodes are deleted but it leaves open to interpretation what deleted
> actually means.
> 
> It should say that the nodes are detached from their parents and queued
> for destruction immediately before deferred update behavior.
> 
> Finally, the behavior of properly destroying all 'deleted' nodes before
> deferred update behavior occurs should be mentioned at the beginning of
> Section 10 on XForms actions.
> 
> 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
> 
> 
Received on Tuesday, 11 September 2007 09:38:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 December 2014 20:06:25 UTC