[
Lists Home |
Date Index |
Thread Index
]
[Joe English]
>
> 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"]
>
Aha! I thought I had found every occurrence of "error value", but I must
have had the 1000-yard stare when I got to that one.
> 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.)
>
>
I'm very comfortable with referring to a clause rather than repeating the
boilerplate.
I just want to make sure that it's easy to test for, and that how we test
for error_value won't vary between implementations (like getting the string
"NaN" - you know what to look for).
Cheers,
Tom P
|
