W3C home > Mailing lists > Public > public-forms@w3.org > June 2007

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

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 19 Jun 2007 13:29:53 -0700
To: ebruchez@orbeon.com
Cc: public-forms@w3.org, public-forms-request@w3.org, www-forms-editor@w3.org
Message-ID: <OF9729126E.B7F1DB40-ON882572FF.006F9342-882572FF.00709945@ca.ibm.com>
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?

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
06/18/2007 09:18 AM
Please respond to

Re: XForms 1.1 Last Call: comment about 4.4.5 The xforms-insert Event 


Just to make things clear: the request for use case clarification falls 
on John, or on whoever thinks that the "binding" property as currently 
specified should stay in the spec.

If no compelling use case is proposed, we need to drop the current 
"binding" property (but other properties can be proposed if they satisfy 
a use case deemed worthy by the WG).



Ulrich Nicolas LissXX wrote:
> Erik,
> we accept your request to clarify that the empty is string is returned 
by insert
> event binding if none is specified.  We also ask for clarification on 
> feature and its use case, because in general, it is not possible for the 
> author to resolve the value without knowing the context and without 
> whether the binding is a bind IDREF or an XPath expression.
> Regards,
> Ulrich Nicolas Lissé.
> For the Forms WG
>> All,
>> This is a comment about the "binding" property or these sections.
>> Section 4.4.5 says:
>> "The attribute value of the insert action's nodeset or bind attribute."
>> However, both @bind and @nodeset are optional with xforms:insert. We
>> should say what the "binding" property returns when this occurs.
>> By the way, I believe I raised this in the past already, but I am not
>> sure why this property is useful anyway. I would suggest simply getting
>> rid of it unless a compelling use case for it is proposed.
>> -Erik
>> -- 
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/

Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Tuesday, 19 June 2007 20:30:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:52 UTC