Re: XSLT 1.1 comments

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="&lt;ul&gt;&lt;li&gt;...&lt;/li&gt;&lt;/ul&gt" />

Best,

Clark




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