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

All,

A bit more progress on this action item:

- added xforms-action-error [1]
- added error-message info to xforms-action-error
- clarified that xforms-expression-error/xforms-binding-error are
dispatched when the error is not within an action handler
- removed xforms-script-exception and
xforms-script-language-not-supported-exception and replaced with
xforms-action-error
- a few fixes to the script action [2]

Here is the diff:

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

Feedback welcome.

-Erik

[1]
http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_xforms-action-error_Event
[2] http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_script_Element


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

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