RE: RE: syntax sugar for call-template

> > > <xsl:template name="foo">
> > >    <bar>
> > >       <xsl:return select="'bar'" />
> > >    </bar>
> > > </xsl:template>
> >
> > I must say that I really do not like the "return" idea.
> >
> 
> Then how else do you write a function equivalent, say, to distinct() or
> intersection() or max()? Named templates can only return trees, you need
> something that can return arbitrary node-sets, numbers, strings, or
> booleans.

Mike, 

I do not like the idea of "return" inside a "template", I was
only after an abbreviated method to call templates from within
other templates; not call templates from within a xpath expr.

If I had a need for calling a method from within XPath, then
I *do* like your suggestion about a seperate "function" declaration
for creating functions callable from Xpath.  It makes sense 
to have it a seperate construct for the reasons I believe 
you pointed out:

  (a) currently templates do not support returing arbitrary
      node-sets, numbers, strings or booleans

  (b) arguments should be passed by position and not by value

  (c) functions don't need a "output" result fragment as 
      templates already have.

  (d) this new function mechanism can be the same as the
      extension functions (only that the implementation
      is in XSLT).  This is an *acceptable* rendition
      of the script idea, since I does not pollute XSLT 
      with other languages.

In short, I see the 'function requirements as completely
different from the 'template requirements; and as such
they should be seperate constructs.  I belive this is your
position isn't it?  IMHO, trying to merge them will be 
FAQ heaven....

Kind Regards,

Clark
        




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