Re: [xml] xmlIO extensions

On Wed, Oct 29, 2003 at 10:34:31PM +0100, Christian Engwer wrote:

I am currently using libxml2.4 for a private project. During this work
I was in need for a special xmlIO handler.

I wanted to store all needed files inside one archive (like the
document structure of So I wrote an IO handler for
zip files. I can now read an write files inside a ziparchive. The work
is based on the xmlIO handlers provided with the lib and the zip code
is taken from minizip/miniunzip examples provided with zlib.

I think this code might be usefull for others as well, so I'd like to
publish it. If desired I can adopt it to 2.6 or provide patches to
integrate it into the cvs.

My biggest Problem right now is the license. I read both licenses
(that of libxml and that of zlib/minizip). I think it would be nice to
use the same license for everything in libxml. I think both licenses
are quite equal, so that the usage of zlib-code would not restrict
anything. My code would be published under the term of the MIT License.

If anyone would ike to have a look at the software ...
you can find it at

  Looked briefly at it, interesting but I think you made an error in the
naming scheme. Basically your scheme doesn't seems to be an URI, which mean
you loose the automatic naming support.
  Suppose you have top.xml and chapter.xml in the same zip, that
top.xml references chapter.xml for entities or XInclude, you would
get something like href="chapter.xml" in top.xml . If your naming scheme
was an URI then the libxml2 XInclude processor, given the name for the
top.xml resource and the href="chapter.xml" URI-Reference would automatically
compute the chapter.xml URI based on the top.xml one and would be able to
transparently process the include. I think preserving this property is
really important in practice.
  The problem is that if you take
as the base and try to compute the URI-Reference chapter.xml from it you
end up with 
and not
That's a serious limitation, most of the URI-Reference used for DTD, entities,
XInclude, XPointer, etc... won't work out of the box within the zip archive
while if the naming was done differently all this could "just work".

  Something like zip:///path/to/zip/ is similar to the
file:// scheme, would allow URI-Reference and fragment identifiers.
But it would have the same limitations as file:// , namely it's difficult
to express addressing relative to the curent directory. Maybe the OpenOffice
people have done it's worth checking.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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