Re: ACTION-1868 - Bruchez to summarize problems with error handling and three options for variable type handling

Nick,

Thanks for the feedback. That makes sense. I suppose we still need to *not*
switch models, as we probably cannot have no current model, but in addition
we must change the context to the empty sequence. So I am adding this.

-Erik


On Mon, Oct 7, 2013 at 3:13 AM, Nick Van den Bleeken <
Nick.Van.den.Bleeken@inventivegroup.com> wrote:

>  Hi Erik,
>
>  I think that the specified behaviour is overall quite consistent and
> makes some kind of recovery possible. I don't know if the recovery is
> powerful enough, but you can at least prevent a 'crash' of the form. I
> think that it will be hard to get the form in a consistent state after the
> error though...
>
>  I have one small remark. I would have expected an empty sequence for a
> model switch to a non-existing model (just like other error conditions fall
> back to an 'empty' evaluation context) instead of the current specified
> behaviour (keeping the current evaluation context).
>
> Kind regards,
>
> Nick Van den Bleeken
> R&D Manager
>
> Phone: +32 3 425 41 02
> Office fax: +32 3 821 01 71
> nick.van.den.bleeken@inventivegroup.com
> www.inventivedesigners.com
>
>
>
>  On 02 Oct 2013, at 00:05, Erik Bruchez <erik@bruchez.org> wrote:
>
> All,
>
> ## Introduction
>
> This action item dates back to February 2012 and was revived in our last
> call:
>
>
> http://lists.w3.org/Archives/Public/public-forms/2012Feb/att-0027/2012-02-15.html
>
> ## Error handling with XForms 1.1
>
> First, let's summarize the error handling issues in XForms.
>
> A number of things can go wrong in an XForms page. For most
> attributes, we define a default behavior. For example: "If the src
> attribute is omitted, then…". However errors that happen in XPath
> expressions are handled with the dispatching of two events:
>
> - `xforms-binding-exception` when on bindings (`ref`)
> - `xforms-compute-exception` when somewhere else
>
> Note that `xforms-compute-exception` is also dispatched when there are
> circular dependencies in the model, and that
> `xforms-compute-exception` is used more generally to indicate issues
> with bindings, even when no XPath expression is involved.
>
> This is what XForms 1.1 says:
>
> "At the time of evaluation, an XPath expression must be syntactically
> correct. In addition, the namespaces the expression references must be in
> scope and the functions and variables it references must be defined. If any
> of these conditions is not satisfied, an exception (4.5.2 The
> xforms-compute-exception Event) is raised, except for binding expressions,
> which produce a different exception (4.5.1 The xforms-binding-exception
> Event)."
>
>
> Both these events are not cancelable. This means that the default
> action always runs, and thus always halts XForms processing
> completely. In short, it is never possible to recover from an XPath
> error with XForms 1.1 (or 2.0 in its present state).
>
> This is a problem, because for author have no control over what to do
> in case such errors happen. In particular there is a chance that data
> loss will occur due to a typo in an XPath expression or some
> unexpected dynamic condition.
>
> Better error handling can help alleviate that (for example, by asking
> the user to try to save a draft of the data to recover it later).
> Also, all systems I know have at least one mechanism to recover from
> errors.
>
> ## What we do in our implementation
>
> Since about two years agao, our implementation specifies a different
> behavior, documented here:
>
> http://wiki.orbeon.com/forms/welcome/xforms-error-handling
>
> and in this blog post:
>
> http://blog.orbeon.com/2011/11/more-resilient-error-handling-in-xforms.html
>
> After about two years of experience, we are quite happy with the solution.
>
> ## The new error handling philosophy in short
>
> The XForms processor:
>
> - attempts to recover from errors occurring with XPath expressions,
> bindings, and actions
> - but also dispatches recoverable error events in these cases
>
> The default action of the recoverable errors, for backward
> compatibility, could still be to halt processing. But we could decide
> otherwise.
>
> Because the error events are cancelable, it is always possible to
> recover when desired.
>
> (Although there is no guarantee of being able to recover *meaningfully*.)
>
> The two exception XForms 1.1 events are no longer dispatched:
>
> - `xforms-binding-exception`
> - `xforms-compute-exception`
>
> ## Recovery outside of actions
>
> The XForms processor, when encountering an error with an XPath
> expression (static or dynamic, in XPath 2 terms), or an error with a
> binding, determines a recovery value for the expression.
>
> Here are all the cases that we have identified:
>
> 1. For control bindings, model bindings, values, variables
>    - Upon XPath errors, a default value is chosen:
>        - the empty sequence for bindings and variable values
>        - the empty string for string values
>        - `xforms-xpath-error` is dispatched
>    - Upon binding errors with the `bind` attribute
>        - the binding resolves to the empty sequence
>        - `xforms-binding-error` is dispatched
>    - Upon binding errors with the `model` attribute
>        - the model doesn't change, as if the model attribute was missing
>        - `xforms-binding-error` is dispatched
> 2. For XPath MIP values
>    - Upon XPath errors for `calculate`
>        - the destination value is set to blank
>        - `xforms-xpath-error` is dispatched
>    - Upon XPath errors for other MIPs
>        - the MIP is not modified, as if the attribute specifying the
> property was missing
>        - `xforms-xpath-error` is dispatched
>    - Upon binding errors with complex or readonly content (`calculate`
> only)
>        - the instance value is not modified
>        - `xforms-binding-error` is dispatched to the model
> 3. For the submission `instance` attribute
>    - Upon incorrect instance id
>        - `xforms-submit-error` is dispatched (as in the case of a
> target error with the `targetref` attribute)
>    - Upon binding errors with complex or readonly content
>        - `xforms-submit-error` is dispatched
>
> ## Recovery within actions
>
> - Any error taking place during action processing stops the outermost
> action handler, including:
>    - XPath errors
>    - binding errors with the `bind` or `model` attribute
>    - binding errors with complex or readonly content
>    - missing attributes or unsupported attribute values on action elements
> - `xforms-action-error` event is dispatched to the observer of the action
>    - this includes: controls, `model`, `instance`, and `submission`
> - NOTE: Some actions silently ignore some error conditions, including:
>    - `<setvalue>` pointing to an empty sequence or to an atomic item
> (such as a string) instead of a node
>    - `<delete>` with an empty sequence or an empty overridden context
>    - `<insert>` with an empty or non-element insert context, an empty
> overridden context, or an empty origin
>    - actions with AVTs evaluating to the empty sequence
>    - `<dispatch>`, `<send>`, `<setfocus>`, `<setindex>`, `<toggle>`
> when the target element is not found
>
> ## User-friendliness
>
> Implementations are allowed, if not encouraged, especially at
> development time, to provide informative error messages to the
> developer when errors occur, for example by logging to a console or
> inspector.
>
> ## Summary of new events
>
> The following events are added to XForms:
>
> - `xforms-xpath-error` to indicate a general error with an XPath expression
> - `xforms-binding-error` to indicate a general error with a binding
> - `xforms-action-error` to indicate an error in an action handler
>
> Feedback on this appreciated!
>
> -Erik
>
>
>
>
>
> ------------------------------
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>