W3C home > Mailing lists > Public > public-xsl-query@w3.org > May 2016

Expressions like $X castable as xs:NOTATION

From: Abel Braaksma <abel.braaksma@xs4all.nl>
Date: Sun, 8 May 2016 14:43:38 +0200
To: "Public Joint XSLT XQuery XPath" <public-xsl-query@w3.org>
Message-ID: <2c0d01d1a927$3f7e1020$be7a3060$@xs4all.nl>
The expression "$X castable as xs:NOTATION" is supposed to return a static error, XPST0080. I was wondering why this is, as the type xs:NOTATION is a valid type name. I understand that the error should be thrown with "$X cast as xs:NOTATION" because there is no constructor function for xs:NOTATION, but surely, just *testing* whether it is castable using "castable as" should never raise an error?

It is different for xs:anySimpleType and xs:anyAtomicType because these type names are not available at all.

Furthermore, we say in FO31, section 18.2:

"There is no constructor function for xs:NOTATION. Constructors are defined, however, for xs:QName, for types derived or constructed from xs:QName, and for types derived or constructed from xs:NOTATION."

The last part of this sentence seems untrue "or constructed from xs:NOTATION". How is this possible if there is no constructor?

And I'm puzzled by the general rule that you can cast from specific to generic. I.e., a type derived from xs:decimal (like xs:positiveInteger) can always be cast to xs:decimal. But here we seem to imply that a type derived from xs:NOTATION can never be cast to xs:NOTATION, even though the inheritance hierarchy would suggest we could.

Note, I am not raising this as a bug, as I am quite sure this topic has received ample attention already in the XP 2.0 times, I am just wondering why these discrepancies exist.

Thanks,
Abel 
Received on Sunday, 8 May 2016 12:44:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:43:17 UTC