Re: [xml] xmlIO extensions

[Christian Engwer <christi uni-hd de>]

Hi,

I had a quick glance at the OOo code. It realy seems like they don't
use any uri scheme pointing at files inside an archive. The zip
interface uses 2 filename (zip-srchive and the file inside).

>   Okay, looking at the example, yes this should work.
>   zip:http://somehost/downloads/somefile.zip!/file.xml
> is interesting, however forcing the paths within the archive to be
> absolute sounds a bit strange, what happens if the / after ! is missing.
> Writing back when not using a pure file access is not realistic but could
> be expressed, that's rather good.

For me the jakarta naming scheme would be ok. I could easily integrate
it for local files like
zip:../dir/somefile.zip!/file.xml
and file uris like
zip:file:///home/user/dir/somefile.zip!/file.xml

For non local files it woould be much more work and for now I don't
see to much use in it.

I think the absolute path for the structure inside the archive is
nessesary, because the uri-translation will fail otherwise.

Imagine this:

You have an archive with two files:
archive.zip
  |
  +-> content.xml
  +-> content.dtd

If you open 
zip:/dir/archive.zip!/content.xml
and content.xml referes to an external entity "content.dtd"
libxml will realise that this is a relative request and will build a
new path as followed:
  oldpath:  zip:/dir/archive.zip!/content.xml
->basepath: zip:/dir/archive.zip!/
->newpath: zip:/dir/archive.zip!/content.dtd

If you would open the xml file as zip:/dir/archive.zip!content.xml it
would look like this:
  oldpath:  zip:/dir/archive.zip!content.xml
->basepath: zip:/dir/
->newpath: zip:/dir/content.dtd

You get a wrong directory for the new path.

I would suggest, that I change my naming convention to that from
jakarta, but I will not support the http stuff, because I wuould have
to change the unzip zip stuff and want to finish my project first.

bye Christian