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:

zip://something.zip/path/to/file/in/zip.xml

In my case I know the location of the something.zip 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:
Hi,

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 openoffice.org). 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 
http://hal.iwr.uni-heidelberg.de/~christi/xmlzipio/

  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
    test.zip#zip:top.xml
as the base and try to compute the URI-Reference chapter.xml from it you
end up with 
    chapter.xml
and not 
    test.zip#zip:chapter.xml
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/test.zip/top.xml 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 right...it's worth checking.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | 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/
xml gnome org
http://mail.gnome.org/mailman/listinfo/xml




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