Re: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0

[Jim Melton <jim.melton@xxxxxxx>]

Kurt,

Thanks for the thoughts.  That approach is not currently in there (you 
didn't miss it in the bulk), but it's certainly an approach that should be 
discussed.  I think that the schemaMap component is (as you acknowledged) 
likely to be very controversial, since I doubt that people will be 
enthusiastic about having a stylesheet requirement just for "data type 
conversions"; on the other hand, I understand the relevance and the fact 
that the "user" is who makes the determination for his or her code.

I'll try to be sure it's on the agenda for the next meeting where we'll 
discuss the document.

Thanks again,
   Jim

At 12:09 PM 9/6/2001 -0700 Thursday, Kurt Cagle wrote:
> Jim,
>
> I had a thought while reading the document last night. You've created a
> matrix of casting functions, and I wonder if this is by itself necessarily a
> good idea. Casting of any sort seems to be a larger issue than just
> functional mapping, especially with schema in the mix -- if I create a data
> type that is a restricted version of a base type, then the casting functions
> that you have would still not make it possible for me to cast to the
> restricted type, only to its base type parent. I'm wondering if it might be
> more efficacious to create a generalized casting function as follows:
>
> rslt=cast(expression,typeName[,schemaURL[,schemaMap]]), where expression is
> what is to be case, typeName is the desired cast type, schemaURL would be
> the location of the schema that the expression casts to, and schemaMap was
> an optional stylesheet to handle the casting. If the cast can't be
> determined (it's either ambiguous or out of range), then the function would
> raise an error. The most contentious part would probably by the schemaMap,
> but its the only real way I can see out of handling complex data-type
> casting.
>
> This or something like this may actually be in the spec (its a big spec) but
> just my two cents worth.

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
Oracle Corporation            Oracle Email: mailto:jim.melton@xxxxxxxxxx
1930 Viscounti Drive          Standards email: mailto:jim.melton@xxxxxxx
Sandy, UT 84093-1063           Personal email: mailto:jim.melton@xxxxxxx
USA                                                Fax : +1.801.942.3345
========================================================================
=  Facts are facts.  However, any opinions expressed are the opinions  =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
========================================================================


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