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



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/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]