[Bug 1554] New: [FS] technical: 3.3.3 Handling Dynamic Errors

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1554

           Summary: [FS] technical: 3.3.3 Handling Dynamic Errors
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Formal Semantics
        AssignedTo: simeon@us.ibm.com
        ReportedBy: jmdyck@ibiblio.org
         QAContact: public-qt-comments@w3.org


(para 1 vs para 2 and the rule)
    More subtly, in para 1, Expr is "evaluated within" Expr1, whereas in
    para 2 and the rule, Expri is a subexpression of Expr. The difference
    occurs with functions, where the body of the function *is* evaluated
    within the function-call that invoked it, but is *not* a subexpression
    of that call. This distinction wouldn't be so important if function
    calls "manually" propagated errors from the function body to the call,
    but it looks like they don't.

"There are several expressions, such as [4.6 Logical Expressions] and
[4.11 Quantified Expressions], that do not necessarily propogate an error
raised by some sub-expression."
    But actually, that's true of *all* expressions, as 3.3.4 explains.

"For each such expression, we give specific error inference rules."
    And those rules include something like the rule given in this section.
    (In fact, the rules in 4.6 are exactly equivalent to this rule.)
    So 4.6 and 4.11 are not exceptions to the default rule.

    The problem with this rule, however, is that it allows me to infer an
    error where you don't want me to. Consider it with these bindings:
        Expr   is   let $v := 3 return $v+5
        Expri  is   $v+5     (so Expri is a subexpression of Expr)
        dynEnv is   dynEnvDefault
    If we evaluate $v+5 in dynEnvDefault, we'll get an error, because $v
    is unbound. So we have
        dynEnv |- Expri raises dynError
    This then allows us to conclude
        dynEnv |- Expr raises dynError
    i.e., the whole query raises an error. Which of course it shouldn't.
    The problem is that the rule uses the same dynEnv to evaluate the
    subexpression as the expression, which is not always appropriate.
    So some of the places that refer to 3.3 for their error propagation
    shouldn't:
        4.7.3 Computed Constructors
        4.7.3.2 Computed Attribute Constructors
        4.8.3 Let Expression
        4.12.2 Typeswitch

Received on Tuesday, 12 July 2005 09:26:16 UTC