[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT 1.1 comments (in defence of xsl:script)

Subject: Re: XSLT 1.1 comments (in defence of xsl:script)
From: Francis Norton <francis@xxxxxxxxxxx>
Date: Wed, 14 Feb 2001 15:27:12 +0000
script xslt 1.0

David Carlisle wrote:
> 
> 
> I have no particular desire to fill my stylesheets with a scripting
> language (although perhaps emacs lisp might make a nice extension
> language, or TeX, ....) However I think I disagree completely with the
> above.
> 
I'd quite like to fill my stylesheets with XSLT ... thus my current
campaign to get XSLT included as an xsl:script source language, or to
add the equivalent of Mike Kay's saxon:function.  

> If you just use xsl:script then the situation is exactly the same as
> in XSL 1.0. Your stylesheet will be portable.
> 
Between eg Saxon and MSXML3? Not unless you code, test, document and
optimise your extensions in both java and Jscript, surely?

> If, in XSLT 1.0 or 1.1 you use an extension function from a non XSL
> namespace then your stylesheet will not be portable.
> 
> The only difference is that in XSLT 1.0 you won't in general have any
> idea what the extension function is supposed to do (if it isn't "your"
> namespace") but in XSLT 1.1 you may be able to look at an xsl:script
> element which will specify (in a portable way) the binding of that
> extension function to  some external code library or some inlined script.
> 
> But note it is the use of an extension function that makes the document
> non portable. xsl:script does not _do_ anything. it just specifies the
> binding of extension functions to code, so helps specify what it is
> extension functions are doing. extension functions are the enemy of
> portability, not xsl:script. And they are already in XSLT 1.0.
> 
Surely the point is that xsl:script will encourage the development of a
fragemented codebase that uses language-specific extensions. And
inter-platform portability will suffer as a result. As long as there is
no option to code extension functions in platform-portable XSLT, that
goal will move further out of reach.

Am I wrong, David? If anyone can offer surprise me with a good case for
not implementing XSLT extension functions alongside external ones, I'm
sure you can!

Francis.

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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.