Re: Editorial notes currently in the spec

All,

#5: I removed this one, as the text for xforms-expression-error
already mentions that it is dispatched in case there is an error with
"a value attribute on output and var".

#7: I removed this one as discussed.

#6: I did a bit more thinking about this one. The question is whether
to stop the recalculation sequence algorithm completely and abort
XForms processing when encountering an error while evaluating
`calculate`, `relevant`, `readonly`, or `required`. Doing so is pretty
bad as that means all expression must all succeed, and that means all
expressions must be written with lots of guards built-in, especially
with XPath 23 which support types and have way more opportunities for
dynamic errors than XPath 1.

(The `ref` on binds can fail too, but that happens during rebuild, and
that causes the bind to not point to a node, so that's out of the
way.)

As of XForms 2.0, `relevant`, `readonly`, and `required` are still
leaves: we have not done the work to include them in the dependency
graph via the new MIP functions (which is a shame, but that calls for
implementor feedback). If such expressions fail when run, we don't
know their dependencies (we can know some by static analysis in some
cases, but that's not how the algorithm is specified right now).

MIPs for failed expressions take their default value, as specified. If
there is a static error, the expression will never run properly, and
the processor can put such expression aside and consider that they
evaluate to a constant value. But if an expression fails because of a
dynamic error such as a type error, instance data can change between
two recalculations and cause the expression to succeed.

One solution can be to say that we reevaluate such expressions that
have failed due to a dynamic error as needed, during the subsequent
recalculation, if at least one value has changed in the instance.
Evaluation order doesn't matter as those are leaves. If expressions
succeed, dependencies can become known, and they are added to the
graph. Implementations can optimize this by leveraging static
analysis.

For `calculate`, we do have as of XForms 2.0 (as before) other
vertices that can depend on the associated vertex whose value is
computed. If a `calculate` fails, the resulting value is set to blank,
and we don't know the dynamic dependencies. Upon a subsequent
recalculate, again except for static errors, those calculations that
have failed need to be run, but this time order matters! An
implementation should pick a reasonable evaluation order to give
previously failed `calculate` expressions a chance to succeed again.
Is there such a reasonable order, and if so can we specify it? I am
not 100% sure yet.

- Maybe document order good enough? After all, that's (probably?) what
is done during the first recalculate.
- Could implementation be allowed to be smarter? E.g. static analysis
can give better hints as to the run order.

Solving this is also important as ideally we want MIP functions to be
allowed as part of the dependency graph.

Feedback welcome,

-Erik

On Tue, Feb 11, 2014 at 9:50 PM, Erik Bruchez <erik@bruchez.org> wrote:
> All,
>
> Here are the notes currently present:
>
> 1. What is XForms 2.0
> 2. Complete list [of differences w/ XForms 1.1]
> 3. Type from XML Schema: Feedback is welcome on the approach proposed here
> with regard to XML Schema
> 4. xs:untypedAtomic: Does anything need to be said about providing
> xs:untypedAtomic to the expression?
> 5. xf:output probably shouldn't fail fatally in case of a type error,
> similar to calculate
> 6. Should xforms-compute-exception be dispatched during recalculation?
> 7. The property child element is still under debate, the syntax will
> probably change in the future
>
> #1 and #2: I guess Steven can take care of those?
>
> #3: feedback of course is welcome, but that is general to all new feature in
> XForms 2. Do we leave such notes for LC?
>
> #4, #5, and #6: I need to review those and propose an answer.
>
> #7: It seems that we have settled on that syntax, and I am not sure why the
> comment says it will change. Can anybody recall?
>
> Regards,
>
> -Erik
>

Received on Wednesday, 26 February 2014 05:49:41 UTC