On Mon, Sep 25, 2006 at 06:11:22PM +1000, Michael Day wrote: > >I've just realised that the XInclude mechanism does not support this, as > >it creates its own XML parser context internally and doesn't provide any > >mechanism to pass in user data via the _private field. > > I've tried creating a new function: xmlXIncludeProcessFlagsData(), which > takes an additional void* argument that it passes in to the _private > field of the created XML parser context. This works fine.
Hum, yeah, I don't see how to do this except by adding yet another API with yet another extra data, not nice but I don't see a workaround. > However, I've discovered when parsing an XML document that uses external > entities, the context used for parsing the external entities does not > preserve the _private field of the original parser context. > > eg. If I try to parse the following document using xmlCtxtReadFile: > > <!DOCTYPE foo [ > <!ENTITY bar SYSTEM "bar.xml"> > ]> > <foo>Hello &bar; world!</foo> > > the context that I pass in (with _private field set) will *not* be used > to parse the external entity "bar.xml". Strangely enough, the context > that I pass in *will* be used to parse external DTDs, which seems a bit > inconsistent. Well getting DTD and entity parsing right is unfortunately horribly complex and it took a while to get conformant to the spec. Some of the result is that some inconsistancies like that sneaked in because the design has been revamped at least 3 time. In a sense XInclude is yet another extra layer in that already complex stack. > It seems that further patches to libxml2 will be necessary if I want to > be able to use the _private field of the XML parser context in this way. > Which leads me to ask what the _private field exists for in the first > place, if it cannot be relied upon to be there. What is the use case for > this application data field, and in what situations can it actually be > used reliably? No code can be considered reliable until it has been used over and over in different ways. That has been reliable for other users I guess, you're hitting issues because you go a bit further, sorry no silver bullet around. But we can and should fix issues found when they appear, based on needs and available manpower. > (On a slightly unrelated note, it seems that requirements for a future > libxml3 have been circulating since 2002 or before. Has there been any > progress since then? :) Considering the amount of resources, and how painful the transition from libxml version 1 has been (I only now managed to get rid of it from Fedora !) I have no intent for anything like libxml3 in the foreseable future, sorry again ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [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
