Re: [xsl] Re: What is the best way to cast integer to string in XSLT2?

[Dimitre Novatchev <dnovatchev@xxxxxxxxx>]

Hi Jeni,
 
> > Do any examples exist when such implicit casting would be
> > dangerous/counter-intuitive? If not, then it would be very useful to
> > allow implicit casting to string.
> 
> I agree, but then I think that it would be useful to allow implicit
> casting to a required type, whatever it is, if such a cast is
> permitted. 
 
Absolutely -- this is logical, intuitive and will be a time saver.
 
> Those that support strong typing in XPath 2.0, on the other
> hand, believe that it's useful to be told that you can't use an
> integer where a string is expected.
 
Yes, so an XSLT processor could issue a warning. Only in the "weird" cases this warning will
really be useful to help find the reason of the "weirdness".
 
> 
> There are lots of cases where there *is* implicit casting (of
> xdt:untypedAtomic values) in XPath 2.0 and that casting is
> counter-intuitive (to XPath 1.0 users). For example:
> 
>   @height > @weight
 
Sigh... nothing can be done here, since ">" has now been defined for strings. This is the case
when casting is possible to more than one type and nobody knows what is "correct" for the current
programmer. In this case explicit casting is necessary.
 
To formulate it more precisely, when there's no ambiguity, implicit casting to the type of an
argument should be performed. We agree that this is a job for the XSLT processor (no ambiguity and
perfect knowledge of type signatures) that will significantly help the programmer (prone to
forgetting and commiting errors).
 
> while:
> 
>   current-dateTime() + @delay
> 
> (where @delay is "PT30M", for example) will give you a type error
> because the delay attribute is cast to an xs:double (even though you
> can't actually add an xs:double to an xs:dateTime) and "PT30M" isn't a
> valid double value.
 
The same case again -- the implicit cast must be to the only known correct type for the operation.
 
> 
> Similarly:
> 
>   24 idiv (@indent + 3)
> 
> will give you a type error because the indent attribute is cast to an
> xs:double, which means the result of (@indent + 3) is an xs:double,
> which isn't a valid type for an operand to idiv.
 
Again the same case as above. Someone would argue that the decision to what type to cast will
depend on the order of evaluation (,which in an FP language is not strictly defined). However,
human beings tend to write expressions in a predefined way (e.g. from left to write), so the same
should be used in the casting of types of operands -- of course, after the casting decisions are
made the expression can still be evaluated in any possible order.
 
> 
> Which I guess goes to show that implicit casting coupled with
> polymorphic operators will always give some weird results.
 
Not in the cases where there's no ambiguity. And warnings will be helpful if a few weird cases
still remain.
 
> 
> > In cases like the current one I think such "conversion constructors"
> > should be specified in the XPath data model. This makes writing and
> > understanding a program much more easier.
> 
> The rules for casting between types are specified in the XPath/XQuery
> Functions & Operators document (http://www.w3.org/TR/xpath-functions).
> As I said above, personally I don't see why these rules can't be used
> for implicit casting, 
 
Agreed. What can be done to have this in the spec?
 
> but this seems to go against the strong typing
> ethos of XPath 2.0.
 
And there can be warnings to that effect.
 

 

=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list