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

All,

Some more progress on moving from exception events to error events in the
XPath Expressions Module diffs:

http://www.w3.org/MarkUp/Forms/wiki/index.php?title=XPath_Expressions_Module&diff=3867&oldid=3859

I have also started on the core spec. Diffs:

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

Also:

- added error-message context to xforms-binding-error and
xforms-expression-error so all base -error events have it
- removed xpath-error-description from XPath events (use error-message
instead)
- keep xpath-version-exception

Along the way I found some text that need changing with XPath 2 support, in
particular:

- "Every expression requires an evaluation context" is no longer true
(context item can be absent if expression doesn't depend on it)
- ""If the context item is a node, it will also be the context node. If it
is not a node, there will be no context node"" -> there will be a context
item

I haven't fixed those, but it'd be more than nice to do it. Maybe Nick can
help?

Next step is to complete the event changes to the core spec, and we should
be almost there.

Regards,

-Erik



On Tue, Nov 5, 2013 at 5:40 PM, Erik Bruchez <erik@bruchez.org> wrote:

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