W3C home > Mailing lists > Public > xproc-dev@w3.org > April 2012

Re: EXProc ZIP content representation

From: Mike Sokolov <sokolov@ifactory.com>
Date: Fri, 20 Apr 2012 22:46:44 -0400
Message-ID: <4F921F94.9010803@ifactory.com>
To: Geert Josten <geert.josten@dayon.nl>
CC: Florent Georges <fgeorges@fgeorges.org>, XProc Dev <xproc-dev@w3.org>
I read more about the zip format, and I think in fact there's no reason 
one can't present a directory abstraction that allows for efficient 
retrieval of the contents of a directory.  And it would definitely be a 
benefit. Sorry for the noise.


On 4/20/2012 2:42 AM, Geert Josten wrote:
> I think Florent was talking about the manifest of a zip (for creation or
> investigation). I don't see why the representation of the manifest needs
> to influence the speed of extracting individual files.
> Kind regards,
> Geert
>> -----Oorspronkelijk bericht-----
>> Van: Mike Sokolov [mailto:sokolov@ifactory.com]
>> Verzonden: maandag 16 april 2012 14:46
>> Aan: Florent Georges
>> CC: XProc Dev
>> Onderwerp: Re: EXProc ZIP content representation
>> On 4/15/2012 2:26 PM, Florent Georges wrote:
>>>     BTW, I don't undesrtand why the entries are represented as a flat
>>> list, instead of a tree of dirs and files.  The entry names in a ZIP
>>> file are a flattened view of what they represent: a tree structure.
>>> Wouldn't it make more sense to represent it in XML?  That's what we
>>> have in the EXPath ZIP functions<http://expath.org/spec/zip>   for
>>> instance, and IMHO it is way easier to use with XML technologies
>>> (naturally tree-oriented).
>> One possible danger of presenting a tree directory structure on top of
>> Zip's flattened internal model is that users of the API might expect it
>> to be efficient to retrieve files in a sub-directory. But will it be?
>> I'm in favor of having APIs that accurately reflect the underlying data
>> model so as to avoid surprises like that.
>> -Mike
Received on Saturday, 21 April 2012 02:47:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:17:03 UTC