This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0
- To: "Kurt Cagle" <kurt at kurtcagle dot net>
- Subject: Re: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0
- From: Jim Melton <jim dot melton at acm dot org>
- Date: Thu, 06 Sep 2001 13:23:07 -0600
- Cc: <xsl-list at lists dot mulberrytech dot com>
- References: <4.3.2.7.2.20010906112828.03a38cc0@gmmail.oraclecorp.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
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@oracle.com
1930 Viscounti Drive Standards email: mailto:jim.melton@acm.org
Sandy, UT 84093-1063 Personal email: mailto:jim.melton@acm.org
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