Re: Suggestions for the Master Dependency Graph

okay.

/David

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:08 UTC