RE: Expressions like $X castable as xs:NOTATION

Hmm, maybe the answer is in "19.3.2 Casting from derived types to parent types", which says:

"It is always possible to cast an atomic value A to a type T if the relation A instance of T is true, provided that T is not an abstract type."

Since xs:NOTATION is an abstract type, casting to it from a derived type is not supported. However, that still begs the question why "castable as" should not simply return false always in such cases. Or should we be orthogonal and say that "castable as" always raises XPST0080 for *any* abstract type? I don't think that is useful...

-- Abel



> -----Original Message-----
> From: Abel Braaksma [mailto:abel.braaksma@xs4all.nl]
> Sent: Sunday, May 08, 2016 2:44 PM
> To: Public Joint XSLT XQuery XPath
> Subject: Expressions like $X castable as xs:NOTATION
> 
> 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 13:44:04 UTC