W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2007

[Bug 4873] What errors are caught by Castable As?

From: <bugzilla@wiggum.w3.org>
Date: Sat, 21 Jul 2007 21:42:17 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1ICMiP-0007JH-KG@wiggum.w3.org>

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

           Summary: What errors are caught by Castable As?
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XPath
        AssignedTo: chamberl@almaden.ibm.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


The purpose of the "castable as" operator is to catch casting errors. But it's
not entirely clear from the spec what errors it catches. Clearly ["a" castable
as xs:integer] returns false. I think it's also reasonably clear (well, at any
rate it seems common-sense) that [(1 div 0) castable as xs:integer] doesn't
return false, it throws an error: the failure is not in performing the cast,
but in evaluating the operand of the cast.

Now consider [$x castable as xs:integer], where $x is an element with
element-only content. Evaluating the expression causes $x to be atomized, and
atomization fails for such an element. Has the failure occurred while
evaluating the operand, or while testing castability?

The current text leaves this rather open. It uses the sentence "The expression
V castable as T returns true if the value V can be successfully cast into the
target type T by using a cast expression". This doesn't stand up to scrutiny:
one minute V is an expression, a moment later it is a value.

I suggest the wording: "The expression E castable as T returns true if the
result of evaluating E can be successfully cast into the target type T by using
a cast expression. If evaluation of E fails with a dynamic error, the castable
expression as a whole fails."

This wording would have the effect that an atomization failure would indeed
produce a "false" result rather than an error, because atomization is done as
part of the attempted cast operation, not as part of evaluating E.

(Aside: Given an arbitrary element, how do you test to see whether atomization
will succeed before attempting it? Even if "castable" catches atomization
errors, [$x castable as xs:string] doesn't do the trick, because it will return
false not only for unatomizable elements, but also for elements whose atomized
value is not a singleton....) 

Incidentally, there's another slightly unrigorous phrase in rule 1 of 3.10.2
Cast, where it says "Atomization is performed on the input expression." It
should really say "Atomization is performed on the result of evaluating the
input expression." - you can only atomize a value, not an expression.
Received on Saturday, 21 July 2007 21:42:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:48 GMT