Re: [xslt] DocLoader API Feedback

[David Hyatt <hyatt apple com>]

Ok, the API works like a charm.  I made sure to use libxml's URL 
routines so that I could guarantee that I was comparing two 
libxml-created absolute URIs, and everything works fine.  I have not 
yet done anything with the dicts.  Is sharing a dict only a performance 
optimization, or will things actually malfunction?  In my simple tests 
(so far), everything seems to work fine without my worrying about the 
dicts.

dave

On Aug 19, 2004, at 1:08 AM, Daniel Veillard wrote:

> On Thu, Aug 19, 2004 at 12:38:51AM -0700, Dave Hyatt wrote:
> > How do I know which xmlNodePtr is being processed at the time? It 
> > seems
> > like the URI is not enough to sufficiently disambiguate between the
> > same stylesheet that might be both imported and included by a parent
> > stylesheet.
>
>   That information is not provided. A document cache might actually
> be used for stylesheet since there is xsltDocumentPtr docList; at
> least for includes.
>
> > <stylesheet>
> >   <import href="othersheet.xsl"/>
> >   <import href="othersheet.xsl"/>
> > </stylesheet>
>
>   Not forbidden, note that import and include are processed very 
> differently.
>
>
> > Is the above legal in XSLT? If it is, should I be giving you the exact
> > same xmlDocPtr both times?  If I am supposed to give you two different
>
>   You should *never* give back twice the same xmlDocPtr at that API
> level. This should be very clear from my earlier mails, it replaces an
> xmlReadxxx and the documents are subsequently, modified, sometime 
> subtrees
> are cut off and merged in the main stylesheet. Do not use it as a 
> cache,
> it cannot play that role. It will leak memory, crash and burn !
>
> > xmlDocPtrs, then how can I distinguish between the two loader 
> > requests,
>
>   You always return a different one !
>
> Daniel
>
> --
> Daniel Veillard      | Red Hat Desktop team http://redhat.com/
> veillard redhat com  | libxml GNOME XML XSLT toolkit  
> http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/