Re: LC: xforms-compute-exception and xforms-binding-exception (PR#36)

Hi Erik,

The working group acknowledges that a richer array of exceptions, or possibly a
more general exception with better context information, is needed to more
accurately characterize the exceptions that occur when evaluating XPath
expressions.  The bulk of the problem seems to be that binding exceptions are
being issued for XPaths that are not strictly bindings. In one important case,
we do already have a separate exception, compute exception, that is thrown
instead of binding exception when a fatal error occurs in a MIP expression (i.e.
any attribute of a bind element except for nodeset).  It would be fair to say
though, that xforms-binding-exception is really being treated more like
xforms-binding-or-xpath-exception at this time.

The working group also acknowledges the utility of analyzing the cases currently
associated with exceptions to find those that would be better to have as
non-fatal errors.

The working group resolved to accept these points and to defer the changes to a
future version of XForms.

Thank you,
John Boyer

> 
> All,
> 
> What this is about
> ------------------
> 
> This comment is about xforms-compute-exception and
> xforms-binding-exception, in particular:
> 
> * The clarity (or lack thereof) of the current wording.
> * The need for an xforms-compute-error event.
> 
> The current text
> ----------------
> 
> For reference:
> 
> Section "4.5.4 The xforms-compute-exception Event" says:
> 
>     "Dispatched as an indication of: an error occurring during XPath
>      evaluation for a model item property [...]"
> 
> The introduction to section "7 XPath Expressions in XForms" says:
> 
>     "XPath expressions that are not syntactically valid, including
>      attempted calls to undefined functions, result in an exception
>      (4.5.4 The xforms-compute-exception Event), except for binding
>      expressions, which produce a different exception (4.5.1 The
>      xforms-binding-exception Event)."
> 
> Section "7.6 The XForms Function Library" says:
> 
>     "If an error occurs in an XPath function, an
>      xforms-compute-exception occurs if the function appears in the
>      expression of a model item property. If the error occurs in a
>      function that appears in any other XForms attribute that contains
>      an XPath expression, such as nodeset, ref or at, then an
>      xforms-binding exception occurs."
> 
> Section "7.12 Extension Functions" says:
> 
>     "XForms Processors perform this check at the time the document is
>     loaded, and stop processing by signaling an exception (4.5.4 The
>     xforms-compute-exception Event) if the XForms document declares an
>     extension function for which the processor does not have an
>     implementation."
> 
> One thing to keep in mind
> -------------------------
> 
> As hinted by Mike Kay in his LC comments [1] from the XSL and XQuery
> WG, XPath 2.0 explicitly makes a distinction between two types of
> errors: static errors (which do not require evaluating expressions,
> i.e. typically syntactic errors) and dynamic errors (errors occurring
> while evaluating the XPath expression).
> 
> I think that in XPath 1.0, the behavior of standard functions is
> designed so that you don't get dynamic errors. For example, converting
> a string to a number type will return NaN if the conversion fails,
> while with XPath 2.0 casting an xs:string that does not represent an
> integer to xs:integer will raise a runtime error.
> 
> This said, while XPath 1.0 does not make this distinction explicitly,
> XForms does talk about a type of dynamic errors in the intro to
> section 7.6 under "if an error occurs in an XPath function", and also
> mentions errors occurring "during XPath evaluation" in section
> 4.5.4. So we do have, in XForms 1.0, static AND dynamic XPath errors,
> whether these terms are used or not.
> 
> The problems
> ------------
> 
> I am confused by the current text, which in my eyes contradicts itself
> at times, and does not clearly lay out the intent of these events.
> 
> 1. Section 7 indicates with the words "binding expressions" that the
>      intent of a "binding exception" is to signal there is an error with
>      a binding, whether the syntax is incorrect or whether there is a
>      runtime error. I understand this to regard any XPath expression not
>      only in xforms:bind/@nodeset but also in @ref/@nodeset expressions
>      that bind controls to instance data.
> 
>        Issue #1: Section 7.6 says that syntax errors in attribute @at
>        dispatch xforms-binding-exception. I think that this is wrong, as
>        @at does not define a binding at all.
> 
>      (Note that xforms-binding-exception can also be dispatched for
>      mismatched ids, etc., but here I am only interested in XPath
>      expressions).
> 
> 2. It seems that section 7.12 is the only place where the spec hints
>      that the XForms engine must check the syntax of XPath expressions.
> 
>       Issue #2: It must be made 100% explicit that during XForms
>       initialization (exact place TBD), every single XPath expression in
>       the XForms document is checked for its syntax, and not only for
>       undeclared extension functions. This includes XPath expressions on
>       XForms actions, such as xforms:setvalue/@value, etc., XPath
>       expressions in @if and @while attributes on actions as well, and
>       also @context on actions. Such static XPath errors should dispatch
>       xforms-binding-exception or xforms-compute-exception depending on
>       whether the XPath expression is in a binding or not (see #4 below
>       as well).
> 
> 3. xforms-binding-exception is not cancelable and halts XForms
>      processing altogether. It seems reasonable to do this for MIP and
>      control bindings, because there isn't much you can do with such an
>      error in your XForms document. But what about other uses of @ref
>      and @nodeset?
> 
>        Issue #3: Is it reasonable to dispatch xforms-binding-exception
>        and fatally stop XForms processing for xforms:setvalue/@ref or
>        xforms:insert/@nodeset?
> 
>      I think that the answer to this question is "yes" provided issue #2
>      above is resolved to mandate that all expressions are checked for
>      syntax during initialization.
> 
> 4. @ref and @nodeset on actions are single-node and node-set bindings
>      respecively, but they don't act like MIP or control bindings.
> 
>        Issue #4: Should errors in XPath expressions on @ref and @nodeset
>        on actions dispatch xforms-binding-exception or
>        xforms-compute-exception?
> 
>      An action is not really "bound" to a node as a MIP or control
>      is. So as a form author, I am not sure why xforms:setvalue/@ref
>      would dispatch a different event from xforms:setvalue/@value.
> 
> 5. My understanding is that errors in other XPath expressions,
>      including xforms:bind/@calculate, xforms:insert/@at,
>      xforms:setvalue/@value, etc. should dispatch
>      xforms-compute-exception.
> 
>      But the problem with this is that any error, whether static or
>      dynamic, halts XForms engine processing altogether. This is not a
>      huge problem with XPath 1.0, as mentioned above, since dynamic
>      errors are fairly rare (if possible at all with the standard XPath
>      1.0 function library) and most likely confined to extension
>      functions.
> 
>      Still, it appears reasonable to think that you can recover from
>      dynamic XPath errors, and this is certainly the case when such
>      errors do not occur in bindings. This also prepares XForms for a
>      future where XPath 2.0 is supported, as also suggested by Mike Kay
>      in [1].
> 
>        Issue #5: Dynamic XPath errors should dispatch a new event:
>        xforms-compute-error (and possibly xforms-binding-error), which
>        do not halt XForms engine processing. Whether to support
>        xforms-binding-error for MIP and control bindings can be
>        discussed, but it would make sense for xforms:setvalue/@ref and
>        the likes as those errors can often be recovered.
> 
> A possible strategy
> -------------------
> 
> Here is a tentative strategy based on the above:
> 
> * Dispatch xforms-binding-exception for static XPath errors occurring
>     in @ref and @nodeset expressions on xforms:bind and controls
>     bindings. Static errors must be checked during XForms engine
>     initialization.
> 
> * Also dispatch xforms-binding-exception for dynamic XPath errors
>     occurring in @ref and @nodeset expressions on xforms:bind and
>     controls bindings.
> 
> * Dispatch xforms-compute-exception for static XPath errors occurring
>     anywhere else, including single-node or node-set bindings on
>     actions. Static errors must be checked during XForms engine
>     initialization.
> 
> * Dispatch xforms-compute-error (a new event) for dynamic XPath errors
>     occurring anywhere else.
> 
> While this is done, the relevant text in the spec should be
> consolidated and clarified.
> 
> -Erik
> 
> [1] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0052.html
> 
> -- 
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
> 
>

Received on Wednesday, 24 October 2007 19:16:26 UTC