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

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