This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
[Fwd: Re: XSLT 1.1 comments (fwd)]
- To: xsl-list at lists dot mulberrytech dot com
- Subject: [Fwd: Re: [xsl] XSLT 1.1 comments (fwd)]
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Wed, 14 Feb 2001 14:48:55 -0700
- Organization: Fourthought, Inc
- Reply-To: xsl-list at lists dot mulberrytech dot com
Clark C. Evans <cce@clarkevans.com> asked me to post this to the list
for him:
---------- Forwarded message ----------
Date: Wed, 14 Feb 2001 16:19:53 -0500 (EST)
From: Clark C. Evans <cce@clarkevans.com>
To: xsl-list@lists.mulberrytech.com
Subject: Re: [xsl] XSLT 1.1 comments
On Wed, 14 Feb 2001, David Carlisle wrote:
> > If I use tags that are not in the XSL namespace then its not 100% xsl is it.
> > its XSL + saxon extensions. Its still valid XSL but its not 100% pure BC
> > grown XSL.
>
> that is still true with 1.1's xsl:script. If you don't use functions or
> elements in an extension namespace then the xsl file is portable. No
> matter how many xsl:script elements you might have used.
It seems that many of us think that extension functions are
"acceptable", where xsl:script is a horse of a completely
different color:
Extension functions specify particular functionality
be carried out, and do not specify an implementation.
For each extension function, a small and seperate specification
can be laid out describing the intent of the function.
Implementations can provide this functionality *independent*
of the language the XSLT processor is written in.
With an extension function, I can enumerate what exact
functions are needed; this implies that it is completely
acceptable to implement just a few functions of a given type.
Scripts are embedded code of a completely different language
with it's own interpreter, etc. Certainly one could write
an implementation of each interpreter independent of the
language; but writing function vs writing a full-fledged
interpreter is a big leap in complexity. With scripts,
it is implied that a full implementation of the interpreter
is availabele. Thus, enumeration of additional required
functionality is a very hard problem.
As such, extension functions provide a nice "layer" between
the XSLT script and the transform; with scripts the layering
is given up altogether. I think scripts are an ill-advised move,
all bets at cross-platform compatibilty go out the door.
Many people want scripts beacuse the "modulization" abilities
of XSLT leave alot to be desired, i.e., making a template and
calling a template are just too verbose. This seperate issue
can be solved by an additional namespace "xf" with the following
behavior:
Anywhere, except as a child of "xsl:template",
<xf:func x="y" /> is equivalent to <xsl:call-template
name="func">
<xsl:with-param name="x"
select="y" />
</xsl:call-template>
and when a child of xsl:template,
<xf:func x="y"> is equivalent to <xsl:template name="func">
... <xsl:param name="x"
</xf:func> select="y" />
...
</xsl:template>
Clark
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list