W3C home > Mailing lists > Public > www-forms@w3.org > August 2006

Re: send can violate bind/@constraint

From: John Boyer <boyerj@ca.ibm.com>
Date: Wed, 16 Aug 2006 07:58:37 -0700
To: Ulrich NicolasLissť <u.n.l@gmx.net>
Cc: Erik Bruchez <ebruchez@orbeon.com>, www-forms@w3.org, www-forms-request@w3.org
Message-ID: <OFDD15BCC3.4263E1D2-ON882571CC.005237B1-882571CC.00524CC8@ca.ibm.com>
Yes.  We could/should improve the behavior of send so that it runs the 
actions suggested by the deferred update flags before dispatching 

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer

Ulrich Nicolas Lissť <u.n.l@gmx.net> 
Sent by: www-forms-request@w3.org
08/15/2006 02:46 PM

Erik Bruchez <ebruchez@orbeon.com>
Re: send can violate bind/@constraint

Hi *,

I share your interpretation. This issue is an unintended consequence of 
deferred action behaviour. A simple workaround would be to insert a 
<xf:recalculate/> before <xf:send/>. However, this is not obvious to 
form authors and there should be at least a hint in the spec.

I thought about forcing xforms-submit processing to perform a 
calculation prior to validation. But this might easliy lead to 
inconsistencies: Validation can operate on the relevant subset of nodes 
selected by submit without side-effects, but this doesn't hold for 

Any ideas ?


Erik Bruchez wrote:
> Leigh, Aaron:
> I read the spec the same way, and unfortunately it is true that this 
> behavior breaks the reasonable assumption that submission will only 
> submit an instance that has passed validation AND the "required and not 
> empty" rule (unless you use XForms 1.1's new @validate or @required 
> attributes to disable those constraints).
> I hope that this is an unintended consequence of the spec and that 
> somehow we can fix it in an errata.
> -Erik
> Aaron Reed wrote:
>>> I recently encountered two different XForms processors that do this.
>>> While I think the behavior is incorrect, it may be that it is emergent
>>> from the events described in the spec.
>>> Leigh.
>> As I work on a processor that does not catch the constaint violation 
>> that Leigh mentions, I can give you my interpretation of the spec.  In 
>> xforms-recalculate 
>> (http://www.w3.org/TR/xforms/index-all.html#evt-recalculate), it 
>> mentions that this is where the model item property evaluations occur. 
>> I see not other place in the spec that mentions MIP evaluation.  When 
>> xforms-recalculate happens, we store the resulting node states in the 
>> MDG.  This is what we reference when a submission request occurs.
>> In Leigh's example, during the xf:action, a xf:setvalue happens. 
>> However, all of our remembered constraint, relevancy, etc. nodestates 
>> are for the previous node value until recalculate happens.  Since 
>> recalculation is deferred in Leigh's example, this won't happen until 
>> after the xf:send happens.
>> I believe that we are working in accordance to the spec.  If we are 
>> not, please let us know which MIP evaluations should happen that we 
>> are missing and when they should happen.  I can kindof see in the spec 
>> where  possibly relevancy and constraint should be evaluated during 
>> submission, but that also doesn't make sense to me since I definitely 
>> don't see where @calculate would be processed and constraint could 
>> easily be dependent on the result from an @calculate which didn't run.
>> Have a great weekend all,
>> --Aaron

Ulrich Nicolas Lissť
Received on Wednesday, 16 August 2006 14:59:12 UTC

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