LC: xforms-compute-exception and xforms-binding-exception

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 Friday, 27 April 2007 09:32:13 UTC