Re: [xslt] Few questions

[Daniel Veillard <veillard redhat com>]

On Fri, Sep 12, 2003 at 08:28:01PM +0200, Carlo Contavalli wrote:
> On Thu, Sep 11, 2003 at 05:57:12PM -0400, Daniel Veillard wrote:
> I already have a clear idea of what's going on. I just don't know if it's
> my fault (missuse of a function) or there's something else. I'll try to
> be more clear. Let's say I have a xsl like this:
> 
> <xsl:stylesheet version="1.0" extension-element-prefixes="myown" ...>
> [...]
> <xslt:template match="fuffa">
>   <myown:ext-tag name="fuffa">
>     <xsl:fallback>
>     foo bar
>     </xsl:fallback>
> 
>     foo bar
> 
>     <xsl:value-of select="@attrib" />
>   </myown:ext-tag>
>   [...]
> 
> The function handling ``myown:ext-tag'' needs all the data that
> would be generated by the interpretation of the underlying xslt
> tags (foo bar... <xsl:value-of ...). So, the handler calls
> xsltEvalTemplateString, with the children pointer as an
> argument. xsltEvalTemplateString calls xsltApplyOneTemplate, that 
> reads each node in the tree to produce the correct output. 

  XSLT evaluation doesn't work like that evaluating templates does
not generate strings, I don't know why xsltEvalTemplateString was written
but it is not the general evaluation mechanism. This is far far more complex
I suggest you read transform.c to get an idea of what's going on.

> When xsltApplyOneTemplate finds the <fallback node, it looks for 
> the compiled data in the _private pointer, but the fallback private 
> ptr is NULL, and there comes the error.

  It's possible that the compilation process didn't recurse inside
myown:ext-tag though that would be surprizing.

> Now, the question is, am I wrong using xsltEvalTemplateString? 

  probably.

> Should I use some other function? Should I do something else before
> calling xsltEvalTemplateString (like removing the fallback
> node?)? Is this behavior expected? 

  In a nutshell taking contol of the evaluation like you're
trying to do is very complex. Read the code, read the internal
doc, you will need it. There is no predefined answer, what you're
trying to do is not something I expected to expose.
   http://xmlsoft.org/XSLT/internals.html#processing

> 	- unless I save the value of the variables before changing
> 	  their values. However, I don't know which libxml globals
> 	  were changed by other modules, so I need to save and
> 	  restore _all_ of them. Additionally, I don't want
> 	  to write a code that needs to be changed every time
> 	  a global variable is added or removed from libxml
> 	  sources, so I compile libxml2 with threading enabled 
> 	  (althought my application is not multithreaded) take the 
> 	  address of the global state and copy it somewhere else.
>         - Additionally, I cannot rely on other modules being 
> 	  well-written for my own to work

  That doesn't work. If the module call xmlParserCleanup, the entities
for examples are destroyed, they are global to the library but not handled
by the thread module. If you use code you have no source nor control
to and it makes crazy thing there is no way I can help you, nobody can.
  You're starting to enter a very crazy model which is that you have
binary code (using libxml2) that you can't trust and debug. Very sincerely
I'm not interested in debugging that kind of madness otherwise I would
be selling proprietary software. To be frank it's your problem, I would
just say don't do that.

> The only alternative to rewriting all the modules and to exterminate 
> every future programmer who does not restore libxml defaults on 
> each iteration I can see is to store and restore _all_ global variables 
> (correct me if I'm wrong - that's what I was asking, but looking for
> valid alternatives). 

  There are global variables which are not stored into the thread system
like the entities. They are allocated at initialization time. They use
the memory system as a result.

> so, I can assume the error handlers are the only global variables
> that can be changed by a module and that I need to save and restore
> to make sure I will not compromise another module usability? 

  No, there are others, but they are not "exported" from an API point
of view, the application is not supposed to access them directly, like
   static xmlHashTablePtr xmlPredefinedEntities = NULL;

> I apologize if I haven't been clear enough or if I may sound rude.

  Same here. You're trying to do far too complex stuff IMHO. I don't
know where you design comes from, obviously it wasn't discussed here 
before, libxml2 may not be adequate. But expecting to have different 
module, each which it's own memory handler might work, but I cannot make
any garantee about this, you may have to debug quite a bit before
stabilizing your code. If some of that code is proprietary and has
a different or incompatible model you may well be stuck.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/