xdt:anyAtomicType is in fact an abstract type, and this cast should perhaps
fail. It's succeeding in Saxon because Saxon treats "A cast as B" as a no-op
if A is already an instance of B.

This is slightly questionable: if you do "(3 cast as xs:decimal) instance of
xs:integer", Saxon will give you the answer true(). I personally think that
it's justified, because whenever the spec says that an expression returns a
result of type R, the system is allowed to return a value that belongs to a
subtype of R. So, for example, a system that returns true() for "3 instance
of xs:short" would (in my opinion) be conformant. The spec says that 3 is an
integer, and every xs:short is an integer, so if you return an xs:short then
you've satisfied the spec. I admit to some unease over this interpretation,
because the results aren't interoperable. But when you apply the reasoning
to functions, it's perfectly clear that a user-defined function whose
declared result type is xs:decimal is permitted to return an xs:integer;
therefore I would think the same rule applies to system-defined functions;
and if it applies to system-defined functions, I don't see why it shouldn't
apply to other expressions including casts.

Michael Kay
http://www.saxonica.com/ 



> -----Original Message-----
> From: Frans Englich [mailto:frans.englich@xxxxxxxxx] 
> Sent: 07 July 2005 19:09
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject:  Instantiating anyAtomicType -- why would I?
> 
> 
> Hi,
> 
> I wonder why it is possible to create instances of 
> xdt:anyAtomicType. Saxon 
> evaluates the expression "('foo' cast as xdt:anyAtomicType) 
> instance of 
> xdt:anyAtomicType" as true.
> 
> From my perspective, when taking the recent " What's the 
> difference 
> between xdt:anyAtomicType and xs:anySimpleType?" thread into 
> account, the 
> xdt:anyAtomicType should be abstract since its "role" is to 
> group atomic 
> types(not include composite simple types), and that 
> xdt:untypedAtomic should 
> be used for instantiating values of unknown or "arbitrary" type.
> 
> I wonder:
> 
> * Why is xdt:anyAtomicType not an abstract type? Why wouldn't 
> it make sense to 
> make it abstract?
> 
> * In what circumstances is it useful to have values of type 
> xdt:anyAtomicType? 
> For example, XSL-T 2.0 defines it as one of the available 
> builtin types, but 
> doesn't refer to it otherwise(AFAICT).
> 
> If it was arranged such that xdt:untypedAtomic didn't exist 
> and hence no type 
> promotion from xdt:untypedAtomic existed, and that 
> xdt:anyAtomicType was the 
> type for untyped data which via the "17.4 Casting within a 
> branch of the type 
> hierarchy" became appropriate types, the scenario would look 
> differently(IMHO, AFAICT). And that's also a question, why is 
> it arranged 
> such that type promotion from xdt:untypedAtomic is used instead of 
> down-casting from xdt:anyAtomicType?
> 
> Pointers to available(as in beer, unfortunately) 
> documentation is appreciated.
> 
> 
> Cheers,
> 
> 		Frans