- From: John Boyer <boyerj@ca.ibm.com>
- Date: Fri, 23 Jun 2006 12:00:45 -0700
- To: David Landwehr <david.landwehr@solidapp.com>
- Cc: www-forms@w3.org, www-forms-editor@w3.org, www-forms-request@w3.org
- Message-ID: <OFB54A38CC.3B4F206F-ON88257196.0064E537-88257196.0068713D@ca.ibm.com>
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 --------------------------------------------
Received on Friday, 23 June 2006 19:01:05 UTC