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

Re: Suggestions for the Master Dependency Graph

From: Allan Beaufour <beaufour@gmail.com>
Date: Wed, 22 Mar 2006 09:48:49 +0100
Message-ID: <90d6cb0e0603220048i16dbae2ci87effd8fcee5a7f@mail.gmail.com>
To: "David Landwehr" <david.landwehr@solidapp.com>
Cc: www-forms@w3.org, www-forms-editor@w3.org

On 3/21/06, David Landwehr <david.landwehr@solidapp.com> wrote:
> I would like to suggest three changes to the behavior/algorithm of the
> master dependency graph.

Oh my :)

> 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.

I'm not opposed to the idea, but when will it make sense to make a
cyclic dependency and still have a usable form?

But in general, it might make sense to relax our "fatal errors" a bit.
So instead of just bailing totally, we should fail more gracefully if
the form author handles the errors.

> 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, .)"/>

I'm on, that's a good feature to have.

> 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).

Hmmm. I'm not sure I want more complexity in the MDG. A use case would be nice.

--
... Allan
Received on Wednesday, 22 March 2006 08:48:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 June 2009 18:12:14 GMT