Re: [WIDGETS] Zip Support (request for comments)

FYI, The ECMA Office Open XML - Open Packaging Convention (OPC) [1] is also
based on Zip, and it seems to cover the level of detail that we probably
need for Widgets 1.0. I just found this spec, so I'll need a bit of time to
read through it (120+pages). If anyone has read it, or has any thoughts
about it, then please let me know. FWIW, Open Packaging Convention also
supports ZIP64, so it puts a bit more weight behind the inclusion of Zip64
support in widgets. OPC also has a nice section that clarifies all the
supported features of the Zip APPNOTE in detail.

Kind regards,
Marcos

[1]
http://www.ecma-international.org/news/TC45_current_work/Office%20Open%20XML%20Part%202%20-%20Open%20Packaging%20Conventions.pdf

On 10/4/07, Jon Ferraiolo <jferrai@us.ibm.com> wrote:
>
> Marcos,
> The IDPF went through all of the issues about how to standardize an
> appropriate subset of ZIP and has an approved specification. Look at (
> http://www.idpf.org/ocf/ocf1.0/download/ocf10.pdf) and go to section 4.
>
> I see that you want to disallow the ZIP64 extension, but a 4G limitation
> seems rather small these days. I realize that W3C Widgets are usually meant
> for lightweight things that can download quickly, but W3C should be defining
> orthogonal, reusable technologies that will be suitable for a long time.
> Also, I would argue that any ZIP container capabilities belong in a separate
> specification (that supports 64 bits). The widget specification then could
> refer to this separate ZIP specification (perhaps even the IDPF spec) and
> then say that 64-bit support is not required in conformant desktop widget
> clients.
>
> But more fundamentally, I'm not fully convinced that version 1.0 of the
> Widgets spec has to include ZIP packaging. For example, it looks to me like
> neither Google Gadgets nor Vista Gadgets create a single-file package. This
> makes me suspicious about whether ZIP packaging is a requirement.
>
> Cheers,
> Jon
>
> [image: Inactive hide details for "Marcos Caceres"
> <marcosscaceres@gmail.com>]"Marcos Caceres" <marcosscaceres@gmail.com>
>
>
>
>     *"Marcos Caceres" <marcosscaceres@gmail.com>*
>             Sent by: public-appformats-request@w3.org
>
>             10/02/2007 10:14 PM
>
>
> To
>
> "public-appformats@w3.org" <public-appformats@w3.org>
> cc
>
>
> Subject
>
> [WIDGETS] Zip Support (request for comments)
>
>
> Hi all,
> I'm currently trying to draft up the normative text for the level of
> Zip support that the widgets spec should have. For the spec, I'm
> trying to base the support for Zip on what is currently available
> across various operating systems (Vista, XP, and OSX). I'm basing it
> on those OSs for interoperability. The problem I am having is that
> there is no formal "standard" for what features of Zip are currently
> supported across the "native" OS implementations. The current version
> of the zip APPNOTE (6.3.2) [1], has some nice features, but in no way
> does it match the reality of what is currently implemented in the
> various operating systems. Does anyone know of any definitive
> reference of what parts of Zip are implemented across leading OSs?
>
> The other problem is that the Zip spec is a non-normative text that is
> periodically being updated. I've also found it difficult to locate
> previous version of the specification so it is hard to mandate that
> implementers adhere to a particular version of the Zip spec (eg.
> version 2.0). Any ideas as to how to spec this (without actually
> having to re-spec Zip itself)?
>
> This is what I have got so far...
>
> For the purposes of this specification, A valid Zip file is a data
> object that conform to the Zip File Format Specification (version
> 6.3.2) with the exclusion or support of the following features. In the
> event that a widget user agents encouters Zip file that is in error,
> the widget user agent must abort any processing of the Zip file and
> should inform the end-user with an appropriate localized error dialog:
>
> Zip files must not be split into multiple files or span multiple
> volumes. Zip files that are split into multiple files or span multiple
> volumes are non-conforming. A widget user agent must treat Zip files
> that have been split into multiple files or span multiple volumes as
> being in error.
>
> Zip files must be created using the Deflate compression algorithm as
> specified in [Zip]. Zip files compressed with any other compression
> algorithm are non-conforming. A widget user agent must treat Zip files
> created using other compression algorithms as being in error.
>
> A Zip file must not be created using the ZIP64 extensions defined in
> Section of the Zip File Format Specification. A widget user agent must
> consider Zip files created using ZIP64 extensions as being in error.
>
> A Zip file must not be created using either the Traditional PKWARE
> Encryption or Strong Encryption methods, or any other future
> encryption method, defined in the Zip File Format Specification.
> Widget user agents must treat encrypted Zip files as being in error.
>
> The names of files and directories within a Zip file must be encoded
> in US-ASCII within the range [a-z A-Z 0-9, ,. - _]. A Widget user
> agent must consider Zip files that contain file or directory names
> with characters outside the aforementioned character range as being in
> error.
>
> Kind regards,
> Marcos
>
> [1]http://www.pkware.com/documents/casestudies/APPNOTE.TXT
> --
> Marcos Caceres
> http://datadriven.com.au
>
>
>
>


-- 
Marcos Caceres
http://datadriven.com.au