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

Re: Suggestions for the Master Dependency Graph

From: David Landwehr <david.landwehr@solidapp.com>
Date: Sun, 25 Jun 2006 11:24:49 +0200
Message-ID: <449E5661.5030004@solidapp.com>
To: John Boyer <boyerj@ca.ibm.com>
CC: www-forms@w3.org, www-forms-editor@w3.org, www-forms-request@w3.org



John Boyer wrote:
> 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
> --------------------------------------------

David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
Received on Sunday, 25 June 2006 09:25:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:10 UTC