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 > 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. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
