[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
- From: "Clark C. Evans" <firstname.lastname@example.org>
- To: Robin Berjon <email@example.com>
- Date: Fri, 02 Mar 2001 00:10:47 -0500 (EST)
On Thu, 1 Mar 2001, Robin Berjon wrote:
> My quarrel with xsl:script is that it *immediately* ties an extension to an
> implementation language. This implies either that all implementations will
> have to support the same (set of) languages and thus resort to the usual
> LCD of programming languages (ecmascript) or that stylesheet authors will
> have to include xsl:scripts of equivalent functionality in several
> different languages with every stylesheet that they want to be portable.
> That's just insane.
Hmm. What do you think of...
<xbind:param name="date" type="string" />
<xbind:param name="format" type="string" />
<xbind:return type="string" />
This function formats a date in ISO 8601
according to the format string.
How is this different from xsl:script?
1. This language uses an opaque identifer that is
language independent. This identifier can be
associated in a python based XSLT processor,
for example, to find the required functionality
even if such functionality is not included as
code within the xbind document...
2. This binding syntax tells the W3C processor exactly
what to expect from the imported function. Much like
a Visual Basic "Declare" style to import C functions
from a DLL into the visual basic function space.
3. This clear description (Call it XMLIDL?) can be used
by others to at least try and produce an implementation
in another language...
4. This is a seperate W3C specification, and thus xbind
can be used by DOM, XQUERY, or any other language that
needs to call-out to other programming languages.
5. The above xbind module could actually be stuffed away
in RDDL or similar format so that the binding
information can be queried. In fact the language
independent URI could be a URL to fetch the xbind:module.
6. If the processor knows the xbind name, then the xbind
module isn't even needed, as the functionality can
In short, there are other options if portability of extension
fuunctions are the prime concern. If simple importation of
Java constructs is the goal, then xsl:script as it stands