Subject: Re: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0 From: cagle@xxxxxxxxx (Kurt Cagle) Date: Thu, 6 Sep 2001 08:23:43 -0700 |
This is the approach that the EXSLT community is taking. They begin with XSLT1.1 as a core (somewhat problematic now that XSLT1.1 is dead) but define a set of libraries that provide interface stubs for use in varying platforms. XSLT 2.0 as a core standard should be relative small and self-contained, and I fear that if we include trig functions into the mix, then we get accounting functions and so forth. The key to all of this is still modularity, again an approach you're seeing with EXSLT. I agree with Chris that XSLT should be pervasive, and I suspect it will be, such efforts as .NET not withstanding -- once XSLT gets a toehold on a system, it becomes more and more pervasive in that system over time. -- Kurt ----- Original Message ----- From: "Joerg Pietschmann" <joerg.pietschmann@xxxxxx> To: "XSL List" <xsl-list@xxxxxxxxxxxxxxxxxxxxxx> Sent: Thursday, September 06, 2001 3:12 AM Subject: RE: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0 > "Chris Bayes" <chris@xxxxxxxxxxx> 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 > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] XQuery 1.0 and XPath 2.0 , Joerg Pietschmann | Thread | RE: [xsl] XQuery 1.0 and XPath 2.0 , Jim Melton |
Re: [xsl] RE:what about [@this and , Oleg Tkachenko | Date | [xsl] Trying to find a working XSLT, G. Ken Holman |
Month |