Subject: RE: [xsl] Instantiating anyAtomicType -- why would I? From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Sat, 9 Jul 2005 00:18:35 +0100 |
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: [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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Instantiating anyAtomicType -, Frans Englich | Thread | Re: [xsl] Instantiating anyAtomicTy, Frans Englich |
RE: [xsl] matching positional nodes, Michael Kay | Date | RE: [xsl] Sorting Problem, Michael Kay |
Month |