Re: Suggestions for the Master Dependency Graph

On 3/22/06, David Landwehr <david.landwehr@solidapp.com> wrote:
>
> >> 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?
> >
> >
> It does make sense in spreadsheets. In case of a cyclic dependency Excel
> let you choose if you want a numeric solution and then attempts to
> locate an answer by running the cycle a number of times or stops when a
> specific threshold is reached. The point is really that XForms does not
> allow this kind of implementation specific behavior when the
> specification clearly want everything terminated. Also the cycle might
> come from a series of wrong selections done by the user (it could be
> that a form with a certain level of complexity is unable to prevent such
> a scenario). These selections might turn the form into something the
> user cannot submit however by correcting the errors the form can very
> well turn into something that is valid.

You could argue (and somebody probably will ...) that it is a bad form
that gets you into that problem. But I think it is a good point. Let's
try to fail more gracefully. If there's a good solution for this in
the "spreadsheet world", then let's look at that.

--
... Allan

Received on Wednesday, 22 March 2006 09:17:28 UTC