Re: [xml] What is the _private field actually for?

[Daniel Veillard <veillard redhat com>]

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/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/