Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
| Ok. However, the use-by-reference is still language specific | which, IMHO, breaks portability. From the appendix: | | <xsl:stylesheet | xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" | xmlns:date="uri.any"> | <xsl:script implements-prefix="date" language="java" | src="java:com.example.datestuff.DateRoutines"/> | <xsl:template match="/"> | <OrderDate> | <xsl:value-of select="date:format(/order/date,'MM/DD/YY')"/> | </OrderDate> | </xsl:template> | </xsl:stylesheet> | | It is very clear to me that the above stylesheet will work | if and *only* if the the XSLT processor has built-in java | capabilities. Right. It's also very clear to a processor that doesn't support extension functions in Java that it cannot support this. Easy answer, therefore, to the function-available('date:CurrentDate'). | So, although you may be right about not | "embedding Java", this is close enough to the same concern, | it is an "embedded Java package name". | I'd like to see instead a module based extension facility | that is not language dependent. I (personally, not speaking for the WG here) don't happen to be a believer in some kind of look-it-up-and-magically-download- the-right-(trusted?)-implementation-from-some-central-website- for-the-language-my-processor-can-support-for-the-chip-architecture- and-OS-that-I'm-currently-running-(while-I'm-using-this-on-a-plane) scheme to download and run the "right" implementation of some function. You either supply the implementation along with the stylesheet (embedded or in external objects), or the processor has it built in. <xsl:script>'s whole purpose in life is binding one or more specific implementations of extension functions to a namespace. If you don't want to *bind* and implementation to the namespace, then by your lack of doing this you are depending on your processor's having this function as a built-in extension. You just go ahead and use the function-available('yourpref:yourfunction') and use the yourpref:yourfunction() in expressions as you do in XSLT 1.0 and *hope* that your processor has a way to locate an implementation. | > The contracts that the XSLT engine has with the extension | > function implementation is completely the responsibility | > of each language binding. The language bindings are | > relegated to appendices. | | Doesn't sound like this would encourage portability | among processors written in different languages. It enables and encourages XSLT implementors who care about a particular language and who care about cross-processor portability of user-written XSLT extension functions in that language to agree on all the language-binding specific details amongst themselves. No more, no less. The only requirements it places on their boundless creativity is that they agree: -> On a QName to use to uniquely identify this extension function language binding, and -> The language-specific details of implementing functions using that binding. ______________________________________________________________ Steve Muench, Lead XML Evangelist & Consulting Product Manager BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG Author "Building Oracle XML Applications", O'Reilly http://www.oreilly.com/catalog/orxmlapp/
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format