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

RE: EXProc ZIP content representation

From: Geert Josten <geert.josten@dayon.nl>
Date: Fri, 20 Apr 2012 08:42:29 +0200
Message-ID: <4f08953de70cb7041d855d12291f28f9@mail.gmail.com>
To: Mike Sokolov <sokolov@ifactory.com>, Florent Georges <fgeorges@fgeorges.org>
Cc: XProc Dev <xproc-dev@w3.org>
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,

> -----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 Friday, 20 April 2012 06:42:37 UTC

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