RE: syntax sugar for call-template

On Thu, 15 Feb 2001, Michael Kay wrote:
> >   <xf:func arg="val" />  is-equivalent-to <call-template name="func">
> >                                             <with-param name="arg"
> >                                                  select="val" />
> >                                           </call-template>
> 
> In the past I've considered doing this in Saxon.

About 9-12 months ago I had a meta-stylesheet (XSLT->XSLT) 
which converted the former into the latter.

> But I'm undecided whether the attribute value should be an AVT
> (therefore always yielding a string) or an XPath expression (in which
> case any value can be passed, but strings need to be written in
> double-nested quotes, e.g. arg="'London'"). Any views?

I implemented several months back a simple meta-transform
which added this syntax sugar, and a few other syntax
modifications.  From this experience I strongly feel that
it should be an XPath expression:
 
  (a) Not being able to pass node-sets really reduces
      the usefulness of the construct.

  (b) Having to double-nest quotes is standard when ever the
      "select" or "test" is used.  Therefore, I think this
      is expected by an XSLT programmer, if not, it will only
      take a few times before they learn... *evil grin*

Alternatively, this mechanism could work like regular non-xslt
attributes.  Thus, "hello" is a string, but "{hello}" is a node
set of child 'hello' nodes.  I'm not sure I like this.

> (Though actually, I've also held off because I'm reluctant to implement
> non-portable extensions if they provide nothing more than a saving in
> keystrokes ...)

A small amount of sugar at the right spot can really 
make the difference of readability.  

Further, when deciding when to break out code into a seperate 
sub-routine it is primarly a "space" choice.  If I can "inline" 
the code in 2 lines of code, why would I want to put in a 5 line
call-template?  Now, if I can put in 1 line "sugar call",
better modulization results.

It could be written up as a very simple specification and
I'm sure most of the XSLT implemenations would happily 
implement it.  But more importantly, it would be cool if
this made it into XSLT 1.1 ; after all, if we are going to 
add a huge framework to make extension functions work better,
why not add a small amount of syntax sugar to make the
language more "useable".  In the mean time, a simple 
meta-transform will do the trick...

Clark

P.S.  Thank you for considering this and giving 
      it some thought.








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