- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Thu, 4 Oct 2007 06:05:52 -0700
- To: "Marcos Caceres" <marcosscaceres@gmail.com>
- Cc: "public-appformats@w3.org" <public-appformats@w3.org>
- Message-ID: <OF85EF53CE.1BEAD6E2-ON8725736A.0046EA3A-8825736A.0047F311@us.ibm.com>
As I remember, there are considerations with the OPC spec:
1) OPC spec attempts to preserve all of the platform specific (particularly
Windows-specific) extensions to ZIP so that they round-trip successfully. I
don't remember the details here, but clearly one can understand why MS
would produce a spec which would optimize that particular workflow. Because
of the approach taken in the OPC spec, it takes several pages to document
the clarifications in OPC's use of ZIP versus the original Zip appnote.
2) Last I looked, MS did not have a separate spec for OPC but instead
defined this technology not once but twice in both the Office Open XML spec
and the XML Paper Specification. (Maybe this has changed)
3) Open Office XML failed to get approval in its most recent vote at ISO. I
don't keep track of whether ECMA has approved Open Office XML. I assume it
has, otherwise it wouldn't have been sent to ISO. Whatever, you need to
check on where Open Office XML stands as a referenceable "standard".
4) If you go the OPC route, you will want to make sure MS provides a
specific covenant not to sue over patent claims that might have. I believe
they have issued a covenant not to sue on Open Office XML, but that's
different than providing a covenant not to sue over technology extracted
from one of their specs.
Jon
"Marcos Caceres"
<marcosscaceres@g
mail.com> To
Sent by: "public-appformats@w3.org"
public-appformats <public-appformats@w3.org>
-request@w3.org cc
Subject
10/03/2007 11:08 Re: [WIDGETS] Zip Support (request
PM 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
Inactive hide details for "Marcos Caceres" <marcosscaceres@gmail.com>
"Marcos Caceres" < marcosscaceres@gmail.com>
"Marcos
Caceres" <
marcosscaceres@
gmail.com>
Sent by: To
public-appforma
ts-request@w3.o "
rg public-appformats@w3.o
rg" <
public-appformats@w3.o
10/02/2007 rg>
10:14 PM
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
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic27766.gif
- image/gif attachment: ecblank.gif
- image/gif attachment: 2D535402.gif
- image/gif attachment: 2D729512.gif
Received on Thursday, 4 October 2007 13:13:15 UTC