Re: [xsl] Instantiating anyAtomicType -- why would I?

[Frans Englich <frans.englich@xxxxxxxxx>]

On Friday 08 July 2005 23:18, Michael Kay wrote:
> xdt:anyAtomicType is in fact an abstract type, and this cast should perhaps
> fail.

If it is abstract, why should it /perhaps/ fail? Shouldn't it then always 
fail?

Also, where is it normatively asserted that the type is abstract? I can't find 
it here, for example: http://www.w3.org/TR/xpath-datamodel/#types-predefined

(it is likely me who don't find my way in the specs; is the property inherited 
from any of its base types?)

I (also) think it would make sense for it to be abstract. If it is missing in 
a specification, this should perhaps be submitted as a spec issue?

> 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.

I am too unsure on these areas too contribute anything useful to the 
discussion, but the paragraph was interesting and it spurred my wondering.


Cheers,

		Frans

> 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: [xsl] 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 "[xsl] 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