4873 2007-07-21 21:42:16 +0000 [XPath] What errors are caught by Castable As? 2007-11-16 11:59:58 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 2.0 Recommendation PC Windows XP RESOLVED FIXED P2 normal --- 1 mike chamberl public-qt-comments oldest_to_newest 15898 0 mike 2007-07-21 21:42:16 +0000 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. 15979 1 chamberl 2007-07-31 17:48:55 +0000 On July 31, 2007, the XSLT and Query working groups reviewed this bug report and agreed to make the wording change suggested by Michael Kay. --Don Chamberlin (for the joint working groups) 17779 2 mike 2007-11-16 11:59:58 +0000 The agreed change will be implemented in erratum XP.E5 for XPath, and XQ.E5 for XQuery.