Re: [xslt] XSLT Problem with recursiv functions

[Shaun McCance <shaunm gnome org>]

On Wed, 2003-11-05 at 08:53, Bernd Lang wrote:
> Hello,
> 
> we detected a xslt problem in the Redhat 3.0 enterprise edition.
> We use in our project xsltproc for generating C code. In our
> stylesheets we implemented some recursiv functions.
> 
> All this stuff worked under RH8.0 which uses the libs
> 
> libxslt-1.0.19-1
> libxml2-2.4.23-1
> libxml2-devel-2.4.23-1
> 
> In the new version RHEL3.0 we detected many new libs related to the xslt 
> stuff.
> 
> libxslt-1.0.33-1
> docbook-style-xsl-1.61.2-2
> libxslt-devel-1.0.33-1
> libxml2-2.5.10-5
> libxml2-python-2.5.10-5
> xml-common-0.6.3-14
> xmlto-0.0.14-3
> libxml2-devel-2.5.10-5
> libxml-1.8.17-9.1
> 
> With the new version the recursiv functions doesn't work anymore.

Put somewhat simply, the problem is that the libxslt implementation of
EXSLT functions doesn't provide a top-level scope for variables.  You're
expecting func:function to behave like xsl:template, where variables are
independant of the caller and override global variables.

Unfortunately, this isn't the way the implementation works.  A function
is executed in its calling template's scope.  So when a function calls
itself recursively, variable definitions from the first call are still
in scope.  Thus, the variable will fail in nested calls, because it's
trying to override an already-existing variable.

The EXSLT functions are rather flaky.  They're not very well specified,
so it's really not always clear how they should behave.  With respect to
params and variables, they should *probably* behave exactly as templates
do.  At least, that's what I think most people would expect.

A couple of months ago, I looked into making some changes to libxslt's
implementation of EXSLT functions.  On this particular issue, there
didn't seem to be a really clean way of changing the behavior without
making accomodations for it in the main part of libxslt.  That may be
doable, but it wasn't a high priority for me.

I'm rather fond of EXSLT functions in principle.  But they're not well
specified, and there are some problems with implementing them as an
extension in libxslt.  The problems might not be unsurmountable, but
they're also not a top priority.  I recommend strongly against using
them in any production-level code.


As for why this ever actually did work, I have no idea.  There don't
seem to be any relevant changes in the functions implementation or in
the scope-setting code in xsltApplyOneTemplate.  It's possible that
there was once a bug in the variable-handling code, or that I'm just
missing something completely.

--
Shaun