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

All,

I have made a bit of progress on "ACTION-1957 - Write spec text for error
handling", but I am not done yet.

I have a few comments/questions for the group:

1. With xforms-action-error, we don't need xforms-script-exception and
xforms-script-language-not-supported-exception. I suggest removing these
two events. Possibly, we can add context information to xforms-action-error
to specify that the error is with a script or the script language.

2. Instead of xforms-xpath-error, which I had suggested, I now suggest
xforms-expression-error, as that is expression language-independent.

3. I had said that an incorrect instance attribute on xf:submission would
dispatch xforms-submit-error, but XForms 1.1 dispatches
xforms-binding-exception. Unsure which one to pick here. Wouldn't you want
to have xforms-submit-error for any error with the submission?

4. XForms 1.1 is contradictory for xf:send/@submission:
    - the action says "If this attribute is given but does not identify a
submission element, then the send action has no effect"
    - xforms-binding-exception event says: "a submission attribute that
fails to point to the ID of a submission element"
    - I suggest ignoring, as the action says (could also do an action error)

As a first step I have added the two new events here:

http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#Error_Indications
http://www.w3.org/MarkUp/Forms/wiki/index.php?title=XForms_2.0&diff=3843&oldid=3842

Comments welcome,

-Erik


On Tue, Oct 8, 2013 at 5:30 PM, Erik Bruchez <erik@bruchez.org> wrote:

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