This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: RDDL as a delivery vehicle for XSLT extensions?
- To: xsl-list at lists dot mulberrytech dot com
- Subject: RE: [xsl] RDDL as a delivery vehicle for XSLT extensions?
- From: Peter Flynn <peter at silmaril dot ie>
- Date: Sat, 3 Mar 2001 09:07:47 +2400
- Reply-To: xsl-list at lists dot mulberrytech dot com
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