Re: [xml] entity resolver callback context not too useful for python

[Rush Manbert <rush manbert com>]

Daniel Veillard wrote:
> On Mon, Nov 28, 2005 at 10:06:07PM -0500, Brad Clements wrote:
>
> > What appears to happen when processing document() during the 
> > transform:
> >
> > 1. libxml2 creates a new parsing context, 
> >
> > 2. libxml2 calls the entity resolver with that new context
> >
> > 3. libxml2 parses the returned data
> >
> > But since this is a new parsing context, I've never seen it before, so even 
> > if I could find out my original xml/xslt document's parsing context, they  
> > wouldn't be helpful because they're not related to the freshly created 
> > context made during entity resolution.
> >
> > It's a bit of chicken-and-egg problem, because loading the original xsl file 
> > might also do entity lookups (xsl:include), so even before I get a 
> > document handle, I could be doing lookups.
> >
> >
> > My hack-around solution was to use xmlReadDoc, and pass in a 
>
>
>   use xmlReadCtxtDoc with a context you created yourself

I think Brad has found the same problem I wrote about a couple of weeks 
ago on the libxslt list. You can use xmlReadCtxtDoc and recover _private 
in the external entity loader. That works fine. But when you are 
applying a XSL transformation and document() gets processed, the context 
pointer that gets passed to the entity resolver is not something that 
you can use to recover context. There is nothing there that refers back 
to the original document or the top level stylesheet. Depending on what 
path gets you to the external entity loader, the context pointer  can 
contain a xsltStylesheetPtr, a xsltTransformContextPtr, or NULL. This is 
a fairly big problem if you want to do anything more complicated in a 
multi threaded environment than parsing a single level XML document.

I hacked around this by finding all of the calls I make to the library 
that end up calling the external entity loader, then protecting them 
with a mutex. That lets me stash my context information for the thread 
that owns the mutex and recover it in the entity loader code. That's 
okay for me because I know my documents are small and the 
transformations are fast. I might be in trouble if I didn't control the 
parameters so closely. (If I was running my code on a public server, for 
instance.)

> > mangled URI with my own custom scheme, whose netloc can be 
> > dereferenced back to the originating 'http request context'.
> >
> > It'd be handy of something like xmlReadDoc could be given some opaque 
> > value that would be passed to the entity loader. Further, that opaque 
> > value would have to be set on all documents loaded during the parsing 
> > process.
>
>
>   At the C level there is a _private pointer for parsing contexts that
> application can use to associate application data with that specific 
> processing.

It's the same answer here. This works for xmlReadCtxtDoc, and may work 
throughout libxml2 as long as you don't do XSLT, but it doesn't work 
when you try to use libxslt and apply XSL transformations.

- Rush