Re: [xslt] Proposed enhancement to some libxslt-0.6.0 routines

[Daniel Veillard <veillard redhat com>]

On Tue, Mar 27, 2001 at 10:26:10AM -0800, William M. Brack wrote:
> We have encountered a few problems with the current library.

  Hi William,

I have read your mail, but didn't had time yet to apply the suggested changes
I'm fairly busy with other stuff this week.


> 1) apply-template with parameter is not correct
> The problem occurs in transform.c.  When xsltApplyTemplates
>calls xsltProcessOneNode, that routine clears variables (including
>parameters) before calling xsltApplyOneTemplate.  Furthermore,
>if xsltDefaultProcessOneNode is called, the same problem occurs.
>Our proposed solution is to remove this clearing of variables (since it
>is done by xsltApplyTemplates before calling xsltProcessOneNode).


there is just one potential problem in removing the clearing of variables
in xsltProcessOneNode, if I remember correctly, you submitted this patch
previously and I had to take it out because it broke a number of tests
from the XSLTMark. The correct change is probably to add a parameter
to xsltProcessOneNode defining whether the variable cleaning should be done
and check in the various routine calling it whether this is needed or not.


> 2) there are major problems with the position() and last() functions
> There are two sub-problems involved.  First, when processing of the
>stylesheet first begins, a call is made to xmlXPathNewContext.  That
>routine initializes the two variables proximityPosition and contextSize
>to be "illegal" values (-1) which (we suppose) is okay for the general
>case, but not okay for xslt (where the initial "position" should never
>be undefined).  The result of this problem is  "crash", for example, if
>position() is used on a global variable.  Our proposed solution is to set
>the two variables to zero after the call within xsltNewTransformContext.

  makes sense.

> The second sub-problem concerns the handling of these same two
>variables, proximityPosition and contextSize, within the remaining code.
>We found that they were being "corrupted" at numerous points throughout
>the code and, after some further investigation, determined that this
>was happening within the routine xmlXPathCompiledEval.  Our proposed
>solution is to insert code to save and restore them each time this
>routine is called - it may be better to change the xml routine, but we
>would rather avoid going into the xml library at this point.

  Well I think this shows a problem in the current xmlXPathCompiledEval
code, and i need to address it in some ways. The suggested change is 
a first step but I need to go back at the XPath spec and double check
where proximityPosition and contextSize need to be saved or restored.

> 3) the "base" path of the document() function should be interpreted relative to the URI of the stylesheet
> If our interpretation of the spec is correct, a small enhancement to functions.c fixes this problem.
> 
> I have attached the patches we have made to solve all of the above points, and would appreciate your consideration of them.  Note that these patches  change the results of some of the docbook tests, but we believe that the changed results are more correct (but not yet totally correct .....).

  I will try to look at this probably over teh week-end,

   thanks a lot for your patches and detailed explanation,

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/