RE: [xml] xmlIO extensions

I have been using a similar xmlIO extraction for several years with
libxml2.  It is also based on the zlib/minizip code.  The format I have
been using is:


In my case I know the location of the file so it doesn't
support currently support searching the filesystem for the file.  I
suppose that could be added using Daniel's suggestion if you require
that the zip file end in '.zip'.  Anyways it works with XInclude
processing and I assume would work with relative URIs though I never use
them with the zip:// protocol.  

I think I at one point had an output handler using the same scheme to
store files into the zip file but I think I removed that b/c I no longer
use it.

If anyone wants to look at my code for comparision I will be more than
happy to post it.  It isn't very many lines.

-----Original Message-----
From: Daniel Veillard [mailto:veillard redhat com] 
Sent: Wednesday, October 29, 2003 3:57 PM
To: Christian Engwer
Cc: xml gnome org
Subject: 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

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
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
compute the chapter.xml URI based on the top.xml one and would be able
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,
XInclude, XPointer, etc... won't work out of the box within the zip
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
to express addressing relative to the curent directory. Maybe the
people have done it's worth checking.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine
xml mailing list, project page
xml gnome org

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