[
Lists Home |
Date Index |
Thread Index
]
Thomas B. Passin wrote:
>
> I also noticed something else [in XPATH 2.0]
> and I'd like some assurance that it isn't a problem, or else that it
> will be handled.
>
> I'm referring to "error value", which will sometimes be returned by XPATH
> 2.0 expressions. I haven't found any place in the draft that says anything
> about how the "error value" is to be handled.
The use of a distinguished "error value" is a fairly common
technique in formal semantics; it's used to simplify the definitions.
In the XPATH 2.0 rec, it says:
| _Error_ is a special value indicating that an error has been
| encountered during the evaluation of an expression. Except
| as noted in this document, if any operand of an expression
| is the error value, the value of the expression is also the
| error value. [2.1 "Basics"]
The "Except as noted in this document" clause is the important
part. The rest of the spec lists several places where the error
value may be introduced, but it rarely needs to specify how it's
handled, because that's covered by this one paragraph. This
shortens the spec considerably.
Consider for example 2.5 "Arithmetic Expressions", where there are
four clauses specfying how an arithmetic expression is evaluated.
This would easily be twice as long if it explicitly accounted for
errors at each step. (By way of contrast, check out the ECMAScript
standard; nearly every clause in that spec is mostly boilerplate text
which redescribes how errors are handled.)
> Thank goodness, the results of performing a logical test (and | or) where an
> operand is the error value is specified (section 2.7). But even here, if
> one operand is false and the other is the error value, the result can either
> be false or the error value.
2.7 is completely unambiguous, and has a simple interpretation:
implementations may evaluate the operands of AND and OR in either
order and are allowed (but not required) to "short-circuit" the
evaluation.
> The result should be specified definitively,
> so that one can know how to test for it. We don't need options here.
This gives latitude to implementors to do things in the most
efficient way possible. If AND were specified as strict in
both arguments (i.e., returning error if either operand is error),
then to conform to the spec implementations would have to fully
evaluate both operands *just to make sure they both succeed*.
AND is frequently specified as strict in the first argument only
in programming languages (i.e., short-circuiting, like C's '&&').
Indeterminate strictness (what XPath specifies) is more common
for database query languages. Presumably the assumption in XPath
is that the implementation knows the optimal evaluation strategy
better than the programmer does. (One might disagree with this
assumption, but at least the REC is unambiguous on this point).
> And again, what is the required behavior when an if-then-else expression
> encounters the error value? It is not specified.
You're right, this one is underspecified. Presumably what's
intended is:
if TRUE then e1 else e2 = e1
if FALSE then e1 else e2 = e2
if ERROR then e1 else e2 = ERROR
but an equally valid interpretation would be:
if e0 then ERROR else e2 = ERROR
if e0 then e1 else ERROR = ERROR
[ earlier ]
> In particular, nothing says
> that you can test whether the returned value is the "error value".
Right; this would require an exception handling facility,
which is probably not needed for XPath.
The upshot of this for XPath users is: don't write expressions that
return errors. The error value construct is mostly of use to XPath
implementors; it specifies how much latitude they have in choosing
an evaluation strategy.
--Joe English
jenglish@flightlab.com
|
