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

Re: Suggestions for the Master Dependency Graph

From: David Landwehr <david.landwehr@solidapp.com>
Date: Wed, 22 Mar 2006 10:02:12 +0100
Message-ID: <44211294.6000801@solidapp.com>
To: Allan Beaufour <beaufour@gmail.com>
Cc: www-forms@w3.org

>> 1) The current specifications states that if the dependency graph isn't
>> acyclic then a xforms-compute-exception must be dispatch which
>> terminates processing. I would to suggest that to be changed in a way
>> where the form isn't terminated since there might be ways the processing
>> could still continue by the help of the author/user. So instead the
>> values could be a predefined value (e.g. NaN) or a value defined by the
>> implementation (would be more useful since that would allow the
>> implementor to create a numeric estimate). I believe this would align
>> the behavior of the XForms calculation engine to the behavior of
>> spreadsheets software.
> I'm not opposed to the idea, but when will it make sense to make a
> cyclic dependency and still have a usable form?
It does make sense in spreadsheets. In case of a cyclic dependency Excel 
let you choose if you want a numeric solution and then attempts to 
locate an answer by running the cycle a number of times or stops when a 
specific threshold is reached. The point is really that XForms does not 
allow this kind of implementation specific behavior when the 
specification clearly want everything terminated. Also the cycle might 
come from a series of wrong selections done by the user (it could be 
that a form with a certain level of complexity is unable to prevent such 
a scenario). These selections might turn the form into something the 
user cannot submit however by correcting the errors the form can very 
well turn into something that is valid.

Best regards,

David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
Received on Wednesday, 22 March 2006 09:02:18 UTC

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