Re: [WIDGETS] Using Zip based on OOXML-OPC, was [WIDGETS] Zip Support (request for comments)

Ok, the following updated text excludes references to any other spec
(but tries its hardest be compatible with OCF, ODF, and OOXML-OPC):

If I don't hear anything back, I'll leave it for public comment for
the next public working draft of the Widgets 1.0 spec [1] (due out
next week) .

=Zip Archive Structure=
This section describes the physical container format for widgets.

For the purposes of this specification, A Zip archive is a byte-stream
or file that conforms to the production of a .Zip file as defined by
the the Zip File Format Specification [ZIP], with the exclusion or
support for the following features and conditions. If a Zip archive
that is either corrupt (meaning that a CRC for a file has failed) or
non-conforming with any of the items listed below is referred to as an
invalid Zip archive. In the event that a widget user agent encounters
an invalid Zip archive during the procedures for processing a widget
resource, the widget user agent must abort any processing and should
inform the end-user with an appropriate localized error dialog.
Appropriate localized error dialogs are left to the discretion of
implementers. A widget user agent must enforce the following
conditions to claim conformance to this specification:

A Zip archive must not be split into multiple files or span multiple
volumes as defined in [ZIP]. A Zip archive that is split into multiple
files or span multiple volumes are non-conforming. A widget user agent
must treat a Zip archive that has been split into multiple files or
span multiple volumes as being an invalid Zip archive.

A Zip archive may be created using the ZIP64 extensions as defined in
[ZIP], but preferably only when a widget resource exceeds
4,294,967,296 bytes (4 gigabytes). A widget user agent must support
the Zip64 extensions to claim conformance to this specification. When
a Zip archive is created using the Zip64 extensions, the version
needed to extract field of each local file header must be set to 4.5.
If a widget user agent encounters a local file header with a version
needed to extract value higher than 4.5, the Zip archive must be
treated as an invalid Zip archive.

Each file in the Zip archive must be compressed using either the
Deflate compression method or stored (uncompressed), as defined in
[ZIP]. A widget user agent must support the Deflate decompression
method defined in [ZIP] to claim conformance to this specification.
For each file in the Zip archive, the compression method field of the
local file header must indicate the compression method appropriately:
If a file has been stored, then the compression method of a local file
header must be 0. If a file is compressed with Deflate, then the
compression method of a local file header must be 8. If the
compression method of a local file header is any value other than 0 or
8, then the Zip archive is non-conforming and a widget user agent must
treat it as an invalid Zip archive.

A Zip archive must not be encrypted using any encryption method
defined in [ZIP]. A widget user agent must treat encrypted an Zip
archive as being an invalid Zip archive. Widget user agent are not
required to support any decryption methods defined in [ZIP] to be
conformant with this specification.

A Zip archive must not be digitally signed using any of the methods
defined in [ZIP] (instead, a Zip archive may be digitally signed using
the procedure for signing a widget resource defined in this
specification). Widget user agents must treat a Zip archive digitally
signed with any method other than the one defined in the Digital
Signature Section of this specification as being an invalid Zip
archive.

The names of files and directories within a Zip archive must only be
encoded in US-ASCII (IBM Code Page 437) or UTF-8, but only if general
purpose bit 11 is set in accordance with the [ZIP] specification (set
of UTF-8 or unset of US-ASCII). A widget user agent must treat a Zip
archive that has files or directory names outside the valid range of
characters for file and directory names as being an invalid Zip
archive. A widget user agent must treat a Zip archive with file or
directory names in any encoding other than US-ASCII or UTF-8 as as
being an invalid Zip archive.

==Extensibility==

A widget resource can be created using proprietary extensions to the
[ZIP] specification so long as the resulting widget resource can be
processed in a interoperable manner across widget user agents. A Zip
archive that cannot be processes by another widget user agent is
non-conforming.



Kind regards,
Marcos

[1] http://dev.w3.org/2006/waf/widgets/

On 10/9/07, Marcos Caceres <marcosscaceres@gmail.com> wrote:
>
>
> On 10/8/07, Jon Ferraiolo <jferrai@us.ibm.com > wrote:
> >
> >
> >
> > Marcos,
> > Looks good, but why is it necessary or desirable to refer to the OOXML-OPC
> specification?
> >
> No, it's not necessary; but I believe it is important to explore all the
> alternatives in detail before settling on a solution. Regarding
> desirability, OOXML-OPC is the only spec that I've seen (thus far) that
> specifies a decent subset of Zip in any significant detail.
>
> >
> >
> >
> > It's been a long time since I looked at that, but my impression was that
> the only real "value-add" of the OOXML-OPC write-up on ZIP was a bunch of
> detail that describes requirements on user agents about various
> platform-specific round-tripping provisions in the ZIP specification, and I
> don't think it is either necessary or desirable to put that burden on
> software developers who want to support the Widgets spec.
> >
> I'm still not convinced about OOXML-OPC has any platform specific stuff in
> it. I am quite certain that I will be able to open my Office2007 files in
> Mac Office 2008... However, I did some tests with Office2007 and seems that
> they don't fully conform to OOXML-OPC (I was unable to open a Zip64 archive,
> but that *may* be 7Zip's fault). I have not been inclined enough to create a
> document that is over 4gb is size to test if office can actually write a
> Zip64 archive.
> >
> >
> >
> > I would also be hesitant about normatively referencing the OOXML-OPC
> specification because of possibilities that other features from OOXML leak
> indirectly into the ZIP description. In general, it is dangerous to refer to
> a single chapter or appendix out of a much larger specification (and they
> don't get much larger than the OOXML spec).
>
> I do agree that making implementers troll through OOXML-OPC might be
> painful... even though I was only referring to about 10 pages out of 120. I
> don't know about the rest of OOXML, but I still think that MS did a good job
> specifying the technical aspects of Zip in OOXML-OPC. (a Google search of
> "OOXML-OPC" and "evil" yields no results;-))
>
>
> >
> >
> >
> > As I mentioned before, there are also IP issues to consider. The OOXML
> specification was not your usual open standards process where a group of
> companies work together to develop a specification. The OOXML specification
> was a special deal between ECMA and Microsoft where the charter for the ECMA
> committee was to define the first version of OOXML as whatever was generated
> by MSOffice ( i.e., the spec is required to match the software), whereas the
> usual standards process is that the software has to match the spec. The
> whole OOXML standards process has been unusual, so I would be especially
> careful regarding IP issues because they might also be unusual. As far as I
> know, Microsoft has not submitted OOXML-OPC to the W3C as a formal
> submission and therefore IP grants aren't guaranteed to W3C, even if
> something has been done with ECMA. (See
> http://www.w3.org/Consortium/Process-20010208/submission.html
> - notice the mention of IPR claims in the second sentence.) Whatever, if the
> WAF committee wants to refer to OOXML-OPC, it is incumbent to involve W3C
> legal in the process to make sure it's OK to make such a reference.
> >
>
> There is no formal decision by WAF to refer to OOXML-OPC (I'm really just
> interested in getting feedback - yours has been extremely helpful, btw!).
> The point is to discuss the techno-political aspects. Out of interest, does
> that mean that references to ECMAScript also puts everyone at risk?
>
> Kind regards,
>
> --
> Marcos Caceres
> http://datadriven.com.au


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

Received on Tuesday, 9 October 2007 07:31:22 UTC