This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[Fwd: Re: XSLT 1.1 comments (in defence of xsl:script) (fwd)]


Again from Clark C. Evans <cce@clarkevans.com>.

---------- Forwarded message ----------
Date: Wed, 14 Feb 2001 16:26:57 -0500 (EST)
From: Clark C. Evans <cce@clarkevans.com>
To: xsl-list@lists.mulberrytech.com
Subject: Re: [xsl] 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.
 
> or (the feature added with xsl:script) There is a standardised mechanism
> within XSL or specifying an implementation or implementations.

The problem with this is that the implementation is specified
in terms of one particular language rather than as a seperate
specification that can have implementations in multiple 
languages, Javascript, Python, C, Java, etc.

> I don't really want to argue with you about your comments on whether
> standardised bindings are a good thing. (Because you know more
> about that side of things than I do) But what I was trying to point out
> that _your_ arguments are arguing about the core issue (whether a
> standardised binding is a good idea) and that xsl:script, despite its
> name, isn't about encouraging the use of scripting languages.

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, 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.

This is the crux of the problem, IMHO.

Clark

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]