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(_dot_)englich(_at_)telia(_dot_)com]
Sent: 07 July 2005 19:09
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--