Re: [xsl] how xslt2 affects usage of programming constructs

[Dimitre Novatchev <dnovatchev@xxxxxxxxx>]

On Mon, 24 Jan 2005 09:11:19 +0100, Bryan Rasmussen <bry@xxxxxxxxxx> wrote:
> 
> 
> 
> Quoting Dimitre Novatchev <dnovatchev@xxxxxxxxx>:
> 
> > >
> > > 2. have these constructs caused you to decrease usage of particular syntax
> > from
> > > 1.0 in favor of the new syntax
> >
> >    Yes, I do not use xsl:call-template
> 
> i suppose you are using functions in its place.

Yes.

> 
> > >
> > > 3. has anyone observed the new ability of being able to increase the logic
> > of
> > > xpath statements has led to a significant decrease in usage of any xslt
> > syntax.
> >
> >
> >    Probably the combined use of xsl:choose inside of an xsl:variable
> > is quite less now.
> >
> 
> i supposed that also if and for-each would be decreased.

An isolated xsl:if that wraps the whole contents of an xsl:template is
still pretty good.

I use exclusively f:map() where normally one would use xsl:for-each.

However, sometimes xsl:for-each is the only way to achieve a specific
result -- e.g. printing a sequence of text nodes as opposed to
producing their concatenated contents (this started happening only
with Saxon 8.2B).

As already demonstrated in my recent code, I am increasingly using the
FXSL HOF wrappers of the corresponding "original" XPath F & Os -- such
as:

  f:mult() instead of '*'

  f:add() instead of '+'

  f:mod() instead of mod

  f:string-length() instead of string-length()

  f:name() instead of name()

  .  .  .  .  .  .  .  .       Put here almost all F & Os  (at present
the wrappers for the date-time functions are still not implemented).

  etc.

Another recent tendency is to implement HOF functions that behave as
specific xslt instructions -- e.g. the f:xsltSort() function.

In all above text the "f" prefix is bound to the following namespace-uri:

    "http://fxsl.sf.net/";



Cheers,
Dimitre Novatchev.