Re: XSLT 1.1 comments (in defence of xsl:script)
> On Wed, 14 Feb 2001, David Carlisle wrote: > > If an XSL file uses an extension function from a non XSL namespace > > then it seems there are at least three choices: > > > > The extension namespace is "known" to the system and it isn't explictly > > declared anywhere (other than being declared as a namespace) > > > > The extension namespace is bound to an implementation of the functions > > in that namespace by some standardised mechanism outside the xsl > > namespace (and possibly outside the xsl file) > > I think these two are adequate. Perhaps RDDL can be used > for "discovering" an implementation of an extension function > in a language available within an XSLT processor. I rather like this idea. I'll have to give it some thought. > Standard bindings for different languages are one thing. This > is just fine. It allows my "java" extension function to work > in multiple java based XSLT processors. However, bindings > should not be required by a processor Bingo! > and it should be clear > that an extension function can be implemened in more than one > language. This is the primary problem. With xsl:script, > a clearly thought-out extension function isn't specified, it > is declared (much too dynamically) in a *particular* language. The counter I've heard to this is that one can declare multiple scripts in all the languages one wants to implement the same function. Does anyone really buy this as anything other than a maintenance disaster? I think it's a bogus counter because no one is going to offer the script in more than their pet language, and then some other person will re-implement it is his own pet language. And so on until the acme-superscript.xslt is loaded down with scripts in every language with an XSLT processor. But wait! There was a bug in that first version of acme-superscript.xslt. Here's a version with the bug fixed. The original xsl:script was modified. Can you say "uh oh"? All this is basic computer science: layered processing, opacity between layers, and dependencies in the form of a directed acyclic graph. xsl:script is simply bad architectural practice. And the politics are pretty ugly as well. -- Uche Ogbuji Principal Consultant uche.ogbuji@xxxxxxxxxxxxxxx +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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