This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT 1.1 comments (in defence of xsl:script)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] XSLT 1.1 comments (in defence of xsl:script)
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Wed, 14 Feb 2001 19:34:32 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> 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@fourthought.com +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