Re: [xslt] [BUG] Win32, xsltproc, libxml, libxslt, <xsl:include/>

[Daniel Veillard <veillard redhat com>]

On Mon, May 13, 2002 at 01:52:47PM +0200, Igor Zlatkovic wrote:
> Welcome back :-)

  thanks, nearly finished digging through mail and spam ...

> >   Argh ... this would be an API change, let's keep this open
> > but I don't think  changing who must free the original document is
> > right, we need to find another way I'm afraid,
> 
> I fully agree.
> 
> The unfortunate thing is that few functions which can fail, just as
> 'xsltParseStylesheetInclude', have no way to inform their caller that
> something went wrong, if they fail. Looking at the code, it is perfectly
> clear that the intention was that such functions leave the stylesheet
> unmodified, or partially modified in such case. The call to
> 'xsltParseStylesheetProcess' turns that knife by half a circle :-)
> 
> What do we do with this?
> * Implement a 'xmlErrno' mechanism similar to errno. This calls for
> thread-safety code in libxslt. Sigh.

  Eeek ... let's not do this mistake again

> * Replace all those silent functions with versions which return an error
> value, set up the wrappers for backward compatibility.

  Basically if a function was returning void, I have no problem
to change its signature to return an int with a non-zero value indicating
an error condition . That's perfectly sane, would that work in this case ?

> * Wait for the API frost to melt away and change the interface :-)

  hum, I prefer to keep libxml2 API compatible as much as possible.

> 
> You name it, I'll take pains to implement it :-)

  Does option #2 work, if yes go ahead !

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/