Re: Designs for XSLT functions (Was: Re: RE: syntax su

> >> Arguments for xsl:template include:
> >> i.  it already exists
> >> ii. it might then be possible to have a template that was used both
> >>     with normal xsl:call-template syntax and as a function (though
> >>     it's arguable whether this is desirable).
> >
> > Well, the nice thing about this is that it would be easy to call
> > existing named templates with the new syntax. Also, one could set up
> > a single template for import into both regular transforms and ones
> > that use exsl:function.
> 
> Aside from the fact that there would be a massive conflict with your
> stated preference for *only* exsl:return.  If only exsl:return were
> allowed, there would be no way to have a regularly called template and
> a function template.

That's what I get for responding as I read rather than digesting the whole 
post first.  Of course you're right, and I'll moot for exsl:function.

> >> 1.b. Top-level declaration vs. declaration within xsl:script
> >
> > As they say in teen movies: "don't even go there".
> >
> > To be more precise, I vote firmly for top-level. Surprise surprise.
> > Perfectly legal under XSLT 1.0, so why not?
> 
> I admit that the rationale for xsl:script is weak if we're only
> talking about user-defined functions in XSLT.  One plausible rationale
> would be, if we have functions declared with xsl:template, that it
> could indicate which xsl:template elements have to comply with the
> function rules (e.g. contain exsl:return, not generate any nodes).
> 
> *If* the xsl:script element is accepted into the XSLT 1.1 canon
> (leaving aside whether it should be or not), I think it is more
> logical to place function definitions in XSLT in xsl:script than at
> the top level, so that it mirrors the definitions of functions in
> other languages. It would also allow XSLT-defined functions to act as
> a fallback when the implementations in other languages have failed (as
> long as implementers implement support for exsl:xslt as an xsl:script
> language).

Well, if it does make it into the language, I agree.  But even if it does, it 
will take a while, and I wouldn't want these function extensions to be 
dependent on XSLT 1.1 anyway.


> > The first exsl:call parameter is the function qname. An even number
> > of further parameters is permitted, and if so, these are the named
> > parameters.
> 
> So exsl:call() would *always* take named parameters - always have an
> odd number of arguments in total - the function name and then paired
> parameters? Whereas my:func() *always* passes parameters by position
> (and could therefore have any number of arguments). (Just wanted to
> make that clear - I think that allowing both position and name in the
> same kind of call will lead to trouble.)

Agreed.  I think it should always take named parameters.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



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