RE: [xsl] RDDL as a delivery vehicle for XSLT extensions?

[Peter Flynn <peter at silmaril dot ie>]

At Thursday, 1 March 2001, Mike wrote:

>> I have a question.  What is the primary reason for xsl:script?
>
>The primary reason is to allow users to write extension functions 
that are
>portable between one XSLT processor and another, as opposed to the 
current
>situation where extensions written for Saxon don't work with Xalan.
I still
>find it hard to understand why this should be thought such an undesirable
>objective.

It's not. But it's not difficult to foresee the situation where powerful 
interests
encourage and recommend the technique of writing everything as a script
in their preferred language, leading to "XSLT" files which are half 
a meg of
script and five lines of XSLT. We've already seen it with HTML, where 
the
"solution" to every need is to write a script, even when the requirement 
can
often be met more portably using markup, because it's "too difficult" 
to learn
or write HTML, and "everyone uses IE anyway". I am already bombarded
with questions (from the Q&A form in the XML FAQ) along the lines 
of "where
do I put my JavaScript or VBscript in an XML file?" [new FAQ out 
soon, BTW],
and it surely cannot be long before one of the browser makers adds 
support
for "Dynamic XML" by recognising scriptlets in attribute values or 
elsewhere
(xhtml:script, perhaps) to permit the render-time transclusion of 
element 
content or whole elements so that the author "doesn't have to bother 
with 
XSL[T]".

It's arguable that this is really a management issue, but my caution 
is simply
to avoid making the descent to this Avernus so easy. I don't have 
a simple
solution, and xsl:script may ultimately be the way to go, but making 
it *appear*
that the answer to all problems is "who cares, you can always write 
a script" 
is at this stage unwise. 

Mike is perfectly correct that portable scripted extension functions 
are desirable. 
The problem is to guarantee portability and ensure that scripts *are* 
extensions, 
not just ways of duplicating existing XSL functionality. 

///Peter



///Peter








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