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 1526 - $x cast as xdt:anyAtomicType
Summary: $x cast as xdt:anyAtomicType
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-09 07:26 UTC by Michael Kay
Modified: 2005-09-29 11:32 UTC (History)
0 users

See Also:

Attachments

Description Michael Kay 2005-07-09 07:26:28 UTC 
(Raised by Frans Englich on the xsl-list at mulberrytech)

We don't seem to have any rule that says what should happen if you write

$x cast as xdt:anyAtomicType

One would think it should fail, because xdt:anyAtomicType is abstract - except
that we no longer seem to say anywhere that xdt:anyAtomicType is abstract.

Saxon 8.4 allows this expression through, because if ($x instance of T) is true
then it treats ($x cast as T) as a no-op.

Michael Kay
Comment 1 Michael Rys 2005-07-11 19:15:59 UTC 
It should not be allowed. This could be one reason to re-introduce the notion 
of abstract types (together with xs:NOTATION).
Comment 2 Ashok Malhotra 2005-07-12 21:21:49 UTC 
The WGs decided on the joint call on July 12, 2005 to add wording to section
17.1 of the F&O harmonizing with the wording in the XQuery/XPath documents to
clarify that casting is not permitted to xdt:anyAtomic type and error XPST0080
is raised if it is attempted.