Re: XForms 1.1 Last Call: comment about 4.4.5 The xforms-insert Event (PR#108)

Hi Erik,

Thanks, that's great.

Regarding the question of whether there was any kind of resolution, no 
there was no resolution to remove the binding property.

Further discussion occurred after the LC response was sent to you.  The 
spec was modified to satisfy your LC comment, but Leigh in particular was 
unhappy with the binding property because it cannot be resolved to 
retrieve the nodeset without knowing whether the binding value comes from 
a bind attribute or a nodeset attribute.

However, I do not feel that such resolution is possible even if we knew 
the difference, nor do I think it is necessary.  In XForms 1.0, the 
usefulness of xforms-insert and xforms-delete events is very low because 
you cannot really can't use them to synchronize operations that occur over 
repeated data except when you have only one block of repeated data (since 
then there is no question about which data has experienced the insert or 
delete).

We need a simple way for authors to be able to detect inserts and deletes 
that are happening to particular repeated data sets when there is more 
than one repeat in the form.  For example, if I have two inserts or 
deletes that operate over A/B/name and X/Y/name, the binding property of 
the events can easily be used to help me figure out which kind of 'name' I 
am dealing with, so I can use conditional logic to respond appropriately.

Granted, if there are two inserts (or deletes) operating over the same 
data, you might get two different values in the binding property.  But 
when this edge case happens, the form author will need to work with care. 
This is what I meant when I said the feature is not without drawbacks. 
However, at the face to face, the alternative was proposed of using a 
generate-id() function.  As I pointed out in my email below, this proposal 
is more flawed because, although it is better for insertion, it completely 
fails for deletion.

For the record, I would point out that comparisons involving the element 
names of inserted or deleted nodes also breaks down in the delete case 
since one is not able to traverse to ancestors of deleted nodes.

Since no one responded in quite some time, I rather assumed the point had 
been sufficiently made and that no further work on issue #108 was 
required.

Cheers,
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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
07/17/2007 03:28 PM
Please respond to
ebruchez@orbeon.com


To
public-forms@w3.org
cc

Subject
Re: XForms 1.1 Last Call: comment about 4.4.5 The xforms-insert Event 
(PR#108)







John Boyer wrote:
> 
> The use case was described at the face-to-face, though it does not have 
> to be solved by the particular property specified.
> 
> The issue is that xforms-insert and xforms-delete are kind of useless if 

> you have no real way of detecting the exact nodes being inserted or 
> deleted (deleted being the harder case because you lose the ancestors).
> 
> The binding property was a simple "thunk" that could often be used to 
> synchronize the operation of insert and delete on a particulare nodeset 
> as being distinct from all other nodesets so that you can write 
> conditional event handlers for xforms-insert and xforms-delete that only 

> take certain actions if a particular nodeset has been mutated.
> 
> One argument against is that the binding property doesn't tell you 
> whether the binding was made by an XPath or an IDREF to a bind.  I'm 
> sure other arguments against will be posted in response to this email, 
> but I wouldn't be happy to see this feature go away unless replaced with 

> something better.  While less than technically perfect in a declarative 
> world, I do not think it is broken really.  It's just that it does what 
> it does, so it only works if you use it with care.  I'd like something 
> better, but we are wanting in that department.
> 
> For example, the suggested alternative was to add a generate-id() 
> function, so the 'if' on the event handler could compare nodes 
> inserted/deleted with those obtained by specific XPaths.  I believe this 

> works for the insert case and fails for the delete case.
> 
> Either way, it would help if you could stay on, Erik, as author of 
> things related to insert/delete and their events.  Would you be able to 
> do this?

I don't think I responded to the last question above. Sure, I have no 
problem with staying in charge of editing the text related to 
insert/delete.

Did we get a resolution on the issue at hand though?

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/