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

Re: XForms 1.1 - target of the xforms-delete event

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 2 Jun 2009 11:31:39 -0700
To: Erik Bruchez <ebruchez@orbeon.com>
Cc: Forms WG <public-forms@w3.org>, xforms <www-forms@w3.org>, www-forms-editor@w3.org, www-forms-request@w3.org
Message-ID: <OF726B63DF.6EB7860E-ON882575C9.0064834A-882575C9.0065C72F@ca.ibm.com>
Hi Erik,

I think there's a misunderstanding.  I wasn't saying that the delete 
*event* would not occur, but rather that the delete *action* itself should 
no-op if you try to delete nodes from multiple instances.

I quite agree that the delete event would be useless if you couldn't count 
on it to let you know whenever nodes are deleted by an XForms supported 
mechanism (unfortunately, you're on your own with the DOM API).

But I think form authors don't lose very much in practice if a delete 
action just simply doesn't work if you do a multiple instance delete.  If 
you want to delete from multiple instances, just write multiple deletes. 
Multiple instance deletes are uncommon, and there is no effective change 
of the number of achievable applications by this limitation since the 
number of instances is static.

Also, my consistency argument is about the actions, not the events.  The 
XForms insert action can only insert into one instance, so it is 
reasonable to have an XForms delete action that can only delete from one 
instance.  The events are just there to target the instance that was 
mutated by the action.

This is the best limitation at this stage of XForms 1.1 since our only 
test on the xforms-delete event tests a deletion from a single instance. 
There is no test coverage for multiple instance deletion, so if we modify 
the spec to say it is possible, then we need a test and two conforming 
implementations.  Given the above claim that there is no loss of power and 
no significant inconvenience in practice, it does not seem worth the 

John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
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
Blog RSS feed: 

Erik Bruchez <ebruchez@orbeon.com>
Forms WG <public-forms@w3.org>
xforms <www-forms@w3.org>, www-forms-editor@w3.org
05/27/2009 11:02 AM
Re: XForms 1.1 - target of the xforms-delete event

> Another possible fix is to have xforms delete ignore nodes which are 
> not in the same instances as the first node, or to no-op entirely.

This would make the xforms-delete event much less useful.

> Insert can only insert nodes into one instance, so it is reasonable 
> to have consistency with delete.   When delete was changed from one 
> node to many nodes, the most urgent requirement we had in mind to 
> satisfy was deletion of a set of children of a given node.  This can 
> reasonably expand to nodes having a common ancestor, but crossing 
> DOMs just seems a little much, esp. without the analogous insert 
> ability.

I don't buy the consistency argument here.

We have to look at events from the perspective of form authors, not 
XForms implementors.

If xforms-delete is an event you can listen to to figure out that 
nodes were inserted into a given instance, then it needs to be 
dispatched to an instance when nodes are removed from it. If 
xforms:delete is able to delete events from more than one instance, 
then it follows that xforms-delete must be dispatched to all instances 
from which nodes were removed.

If we can't rely on an event to be accurately dispatched, then we 
should think about removing that event altogether.


Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Tuesday, 2 June 2009 18:32:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:12 UTC