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