This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT 1.1 comments
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] XSLT 1.1 comments
- From: "Clark C. Evans" <cce at clarkevans dot com>
- Date: Wed, 14 Feb 2001 17:16:48 -0500 (EST)
- Reply-To: xsl-list at lists dot mulberrytech dot com
Sorry about asking Uche to post for me... for some
reason all of my posts yesterday were ignored. I think
the problem in retrospect is on my end. And I asked after
waiting for a while without seeing my post..
Anyway, I wanted to comment on Steve's observations:
On Wed, 14 Feb 2001, Steve Muench wrote:
> In addition to supporting built-in extensions, many popular
> processors support a built-in extension element that
> allows users to create their own user-written extension
> functions in any namespace.
Yes, thus the "implementation" of an extension function
is included in the stylesheet. This, IMHO, is a bad idea.
Better to have the implementation downloadable via RDDL
or some other "find-me-this-extension-function" mechanism.
Where extension functions + resolution protocol puts in
a layer of indirection that allows for portability. Having
the extension functions built into the XSLT stylesheet, is,
IMHO a bad idea.
> What's needed is to specify the various contracts
> at the boundary points between the XSLT processor
> and the extension function implementation language
> environment. These are the concrete details provided
> in XSLT 1.1 for IDL/DOM2, Java/DOM2, and ECMAScript DOM2
> bindings.
I have no problems with extension language bindings;
so long as the implementations of the extension functions
are not in XSLT itself.
> | 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>
>
> This approach would appear to have problems
> passing literal result-tree-fragment arguments
> to templates...
>
> <xsl:call-template name="foo">
> <xsl:with-param name="content">
> <ul>
> <li>One</li>
> <li>Two</li>
> </ul>
> </xsl:with-param>
> </xsl:call-template>
>
> Your example would imply this would be:
>
> <xf:foo content="<ul><li>...</li></ul>"/>
First, this is not a *replacement* for the current syntax,
it is a short-hand that makes template calling and definition
more bareable for simple, "string" arguments.
Second, one would obviously have to do the appropriate escaping
when passing result-tree fragments. I'm not saying this is
pretty, however, I'm proposing a short-hand, not a replacement.
<xf:foo content="<ul><li>...</li></ul>" />
Best,
Clark
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list