Re: RE: syntax sugar for call-template

On Fri, 16 Feb 2001, David Carlisle wrote:
> because if you introduce a system for binding XSLT written code to Xpath
> functions that _only_ does simple cases eg, not cope with qnames as
> function names or node sets as argumnements, then you may find your
> options are severly limited when you come to specify the "full job"
> if you have to keep compatible with a half way solution that has been
> added earlier.

David, thank you for your reply. 

I'm proposing this beacuse I have some 30+ stylesheets
in the work that I'm doing.  And they are quickly becoming
un-manageable.  More importantly, I'm duplicating "template
fragments" that are very common since the overhead for
splitting this into a callable template is so brutal.  This
leads to bad modulization.   I need (ok, have implemented) a 
simple mechanism which is *syntax sugar* for calling templates
that can be used with existing XSLT via a meta-stylesheet.

Thank you for pointing out the "qname" limitation.  This is
interesting, beacuse I've never used qnames as template names.
And, I don't see very many examples out there that do.  So...
I see this as an esoteric case.  I consider myself a heavy
XSLT user and I don't need them.  Now.  XSLT may need a nice
"packaging" mechanism.  However, I hardly feel that qnames will
make my life any easier.  For now, for those concerned with
name collisions, just use a "dnsname" like "func.clarkevans.com"
The chance of a name collision here is, well, infinitesmal.

Your other limitation, is that you can't call the code
through XPath.  This is not a problem that I need to be 
solved.  Most of my XPath expressions are rather simple
already, calling templates from XPath is also esoteric.
Even so, I can call the template, return the results, 
stuff the result fragment into a variable and call
an extension function to-nodeset to make the information
available via XPath.  This isn't simple, but it is very
understandable...

Your final limitation is that I can't pass node-sets as
arguments.  My current solution does not have this problem:

<xf:func one="xpath" />           <xsl:call-template name="func">
                        becomes     <xsl:with-param name="one"
                                       select="xpath" />
                                  </xsl:call-template>

In short, I hardly see why this simple solution is 
"severly limiting".  It may not cover every case in which
people may want to do such a thing... but this isn't
the goal.  The goal is to help template modulization
with *existing and future* XSLT processors. Nothing more, 
nothing less.

Clark


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