This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0


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.

-- Kurt Cagle


----- Original Message -----
From: "Jim Melton" <jim.melton@acm.org>
To: <xsl-list@lists.mulberrytech.com>
Sent: Thursday, September 06, 2001 10:29 AM
Subject: RE: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version
1.0


> Joerg,
>
> Thank you very much for your comments on the Functions and Operators
> document.  Your thoughts on the tradeoffs of core document content versus
> additional libraries of functions are appreciated.
>
> Thanks,
>     Jim (one of the editors of F&O)
>
> At 12:12 PM 9/6/2001 +0200 Thursday, Joerg Pietschmann wrote:
> >"Chris Bayes" <chris@bayes.co.uk> wrote
> > > Well it is a good idea to keep it small I'd like to see xsl become all
> > > pervasive even to handheld devices as well as to mainframe database
> > > apps.
> > > As long as the extension mechanism is well defined and standard across
> > > all xslt 2.0 implementations then things like trig functions can be
> > > added as needed.
> >
> >I'd rather have a small core functionality and some well defined,
> >standardized libraries which implements additional functionality
> >and may be unavailable on certain platforms/implementations.
> >Some possible libraries/packages:
> >  calendar
> >  extended math/trig
> >  user information database access
> >  output control
> >  file system access (file existence, modification date...)
> >  extended node set manipulation (sort, uniq, symmetric difference...)
> >  localised string manipulation (upcase...)
> >  unicode character transformations ("uncompose", making characters from
> >  numbers...)
> >  font property access (fit SVG rectangles around a string)
> >  image property access (format/encoding, width, hight, color depth...)
> >Namespaces woul prevent name clashes, as usual.
> >It would be interesting whether standardized *XSL* libraries would
> >not only include XPath extension functions but also built-in
> >variables (aka constants) and predefined templates. Stuff the processor
> >knows about could be more efficiently implemented/preoptimized.
> >
> >For example:
> ><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
> >     xmlns:xsltrig="http://www.w3.org/1999/XSL/Transform/math/trig";
> >     xmlns:xslposix="http://www.w3.org/1999/XSL/Transform/os/posix";>
> >   <xsl:template match="/">
> >    <xsl:if test="not(xslposix:file-accessible('lock'))">
> >      <xsl:call-template name="xslposix:mkdir">
> >        <xsl:param name="name" select="concat('stuff',xsltrig:sin(0.1 *
> > $PI)"/>
> >      </xsl:call-template>
> >    </xsl:if>
> >   </xsl:template>
> ></xsl:stylesheet>
> >
> >Oh well, i've probably gone much too far...
> >
> >Regards
> >J.Pietschmann
> >
> >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
> ========================================================================
> 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
>
>


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]