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

Subject: Re: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0
From: Jim Melton <jim.melton@xxxxxxx>
Date: Thu, 06 Sep 2001 13:23:07 -0600

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,

At 12:09 PM 9/6/2001 -0700 Thursday, Kurt Cagle wrote:

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

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:

Current Thread