Jeni's Musings

Yes, however in XSLT 1.0 it was often the case that we had to wrap atomic results as children of elements, either because the template produced a sequence of values and there are no sequences in the XPath 1 data model, or even when the template produced a singe value, but we needed to postpone/defer its processing.

When converting such a template to XSLT 2.0, it would be best to replace it with an xsl:function that returns a (sequence of) typed value(s).

What I want to say is that now when we have a better XPath (2.0) data model, even the need to write named templates producing non-text nodes is much less than it was in XSLT 1.0. Therefore, we should recommend that during such a conversion process even a named template that produced wrapped-values shoud now be converted into an xsl:function, producing a typed value or a sequence of typed values. Just the fact that the named template produced element(s) is not in itself 100% sufficient justification to leave it “as is” in the XSLT 2.0 code.

As for using a named template when it produces real (not just value-wrappers) elements, it can also be argued about the benefits of coding this as an xsl:function — of course following a naming convention (such as using make<Name> or gen<Name> names) to make the code more readable.

What would we gain if we were coding this as a named template? It would require more lines of code and also would need an intermediate step before being able to pass its result for additional processing.

A benefit could be that a named-template will not confuse the XSLT processor into performing certain types of optimisation, however the XSLT processor still has to analyze all xsl:functions and isolate those that produce new nodes as the XSLT processor cannot rely completely and solely on the programmer’s discipline.

Cheers,

Dimitre Novatchev