Re: Suggestions for the Master Dependency Graph

Hi David,

I am working on adding these requests to the future requirements document, 
but
I came across some aspects that seemed worth commenting on now.

This is not a note on behalf of the working group.

It is best to take them in reverse.

In #3, you essentially express the desire to allow dynamic dependencies
to be supported by automatically reconstructing the relevant portions of 
the dependency graph while recalculation is proceeding.  This appears
already in Section 4.5 of the future requirements document.

(For other readers, please note that the future requirements document has
not yet been published as a working group note).

In #2, you express the requirement to process self-referencing calculates.
I believe that these are already supported in XForms 1.0, and that you 
have
slightly misinterpreted the spec.  It is not the case that the value of an
instance node is ignored in the calculate for that node.  The spec 
actually
says this:

"References to the current node's value in calculate expressions are 
explicitly ignored, i.e., if an expression associated with a compute 
refers to 
the instance node associated with the compute, then the instance node 
does not take itself as a dependent" 

This means that the node does not enter its own dependency list.  However,
a calculate of the form you gave (below) should be executed as part of
any recalculate that follows a rebuild.  More complicated expressions can
be made to run more frequently by making them depend on something more.

The spec says that authors *should* not use self-references because they 
create
side-effects relative to a pure formulaic system, so conformance across 
processors 
is harder to define and guarantee. But because we do not yet support 
automatic
dynamic dependency reconstruction (#3 above), I believe it will be hard 
indeed
not to get interoperability due to bullet points 2 and 3 at the end of 
recalculate.

The only unfortunate statement appears in bullet point 1, which seems to 
exclude
your calculate from running even after a complete rebuild.  My original 
writing of
the compute system did not have this problem.  Moreover, the recalculation 
algorithm
I did write was only moved to appendix D only to allow a little more 
implementation freedom.
That appendix is not tagged 'informative', and it does state that authors 
are free to vary
the algorithms as long as their optimizations achieve the same effect as 
as the 
method of appendix D.

Therefore, I will be putting together an erratum shortly for the working 
group to consider 
since I do not believe the wording in section 4.3.6 was intended to be in 
conflict with the 
algorithm of appendix D, especially since the result would be that the 
interoperability 
"note" would not make sense.

Finally, with regard to your point #1, I will add it to the future 
requirements document, though 
it will introduce some of the same problems as does support of dynamic 
dependencies.
Specifically, the exact order of computations really starts to matter, and 
especially when
side effect calculations like the one you refer to in #2, which simply may 
no longer behave
in the matter desired by the form author. 

Best regards,
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





David Landwehr <david.landwehr@solidapp.com> 
Sent by: www-forms-request@w3.org
03/20/2006 11:04 PM

To
www-forms@w3.org, www-forms-editor@w3.org
cc

Subject
Suggestions for the Master Dependency Graph







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

-- 
--------------------------------------------
David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------