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

All,

I have now written the details of the error handling. Here is the diff:

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

And here is the text:

http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#Error_Handling

I have:

- renamed the section "Error handling" as it no longer only lists events
- added "10.5.1 Error Recovery Outside Actions"
- added "10.5.2 Error Recovery Inside Actions"

Comments welcome,

-Erik


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

> All,
>
> Yet more progress on this, see the diff:
>
>
> http://www.w3.org/MarkUp/Forms/wiki/index.php?title=XForms_2.0&diff=3857&oldid=3852
>
> - updated the part about errors raised when expressions are incorrect
> - updated AVT text
> - removed dispatch of xforms-binding-exception for xf:submission/instance
> - xf:submission/instance instead causes xforms-submit-error w/ target-error
> - fixed invalid reference to xforms-compute-exception instead of
> xforms-submit-serialize
> - updated summary of events to include new errors
> - updated text for targets of xforms-expression-error
>
> I still need to:
>
> - search for all uses of xforms-compute-exception /
> xforms-binding-exception and update accordingly
> - write the text specifying fallback behavior when errors occur
>
> -Erik
>
>
> On Tue, Oct 15, 2013 at 11:08 PM, Erik Bruchez <erik@bruchez.org> wrote:
>
>> 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
>>>>>
>>>>
>>>>
>>>
>>
>