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

Suggestions for the Master Dependency Graph

From: David Landwehr <david.landwehr@solidapp.com>
Date: Tue, 21 Mar 2006 08:04:51 +0100
Message-ID: <441FA593.2030909@solidapp.com>
To: www-forms@w3.org, www-forms-editor@w3.org

Dear Working Group,

I would like to suggest three changes to the behavior/algorithm of the 
master dependency graph.

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.

2) When collection dependency nodes for building the master dependency 
graph it is clearly specified that reference to the current node's value 
is ignored. I would to suggest this to be changed so it is not ignored 
but instead say something like that references to the current node's 
value does not make a dependency on it-self  which means that a change 
to the value in the xforms-recalculate processing will not loop for 
ever, but a single change will cause a single computation of the value. 
This will enable forms that has the following type of bind/@calculate:
<xforms:bind nodeset="a" calculate="if(.>100, 100, .)"/>

3) Today the following type of binds:
<xforms:bind nodeset="/a/b/c" calculate="../d[number(/a/@pos)]"/>
are static between rebuilds since the predicate expression /a/@pos is 
considered to create dynamic dependencies. I would like to suggest that 
this type of expression is not static between rebuild but updated in the 
xforms-recalculate processing. This would mean a change to @pos will 
update <c>'s value but also change the dependencies for the /a/b/c 
expression to exclude the previous <d> and include the new <d>. This 
will put a harder restriction on the implementor, but will enabled 
flexible forms. To implement such a behavior the implementation might 
have to performed the topological sorting for every recalculation (since 
it is a O(n) algorithm I believe it would be feasible).

I hope you will consider these suggestions.

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 Tuesday, 21 March 2006 07:04:58 UTC

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