This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4873 - [XPath] What errors are caught by Castable As?
Summary: [XPath] What errors are caught by Castable As?
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 2.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-21 21:42 UTC by Michael Kay
Modified: 2007-11-16 11:59 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2007-07-21 21:42:16 UTC
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.
Comment 1 Don Chamberlin 2007-07-31 17:48:55 UTC
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)
Comment 2 Michael Kay 2007-11-16 11:59:58 UTC
The agreed change will be implemented in erratum XP.E5 for XPath, and XQ.E5 for XQuery.