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

Marcos,
Looks good, but why is it necessary or desirable to refer to the OOXML-OPC
specification? 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
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). 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.

Jon



                                                                           
             "Marcos Caceres"                                              
             <marcosscaceres@g                                             
             mail.com>                                                  To 
                                       "public-appformats@w3.org"          
             10/07/2007 01:46          <public-appformats@w3.org>          
             AM                                                         cc 
                                       Jon Ferraiolo/Menlo Park/IBM@IBMUS  
                                                                   Subject 
                                       [WIDGETS] Using Zip based on        
                                       OOXML-OPC, was [WIDGETS] Zip        
                                       Support (request for comments)      
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Ok, in response to Jon's comments, and in the interest of exploring
the OOXML-OPC path, here is some new text for discussion:

=Zip file=

For the purposes of this specification, A valid Zip file 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], but in
conformance with Section 9.2 (excluding section 9.2.6) and Annex C of
the [OOXML-OPC] Specification, and with the exclusion or support for
the following features. A Zip file that does not conform with the
aforementioned sections of [OOXML-OPC] or is in non-conforming with
any of the items listed below, is considered to be an invalid Zip
file. In the event that a widget user agent encounters an invalid Zip
file during the Procedures for Processing a Widget Resource (defined
elsewhere), the widget user agent must abort any processing and should
inform the end-user with an appropriate localized error dialog:

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

A Zip file must be created using the Deflate compression method as
defined in [ZIP]. A Zip file compressed with any other compression
method is non-conforming. A widget user agent must treat a Zip file
created using other compression methods as being an invalid Zip file.
A widget user agent must support the Deflate decompression method
defined in [ZIP] to claim conformance to this specification.

A Zip file may be created using the Zip64 extensions as defined in
[Zip], but preferably only when a widget resource exceeds
4,294,967,296 bytes. A widget user agent must support Zip64 extensions
to claim conformance to this specification.

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

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

The names of files and directories within a Zip file 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 Appendix D of the [ZIP]
specification (ie. set if UTF-8 or unset of US-ASCII). A widget user
agent must treat a Zip file that has files or directory names outside
the valid range of characters for file and directory names (defined
elsewhere) as being an invalid Zip file. A widget user agent must
treat Zip files with file or directory names in any encoding other
than US-ASCII or UTF-8 as as being an invalid Zip file.

Note: Please refer to Appendix D - Language Encoding (EFS) in the Zip
specification for the technical details of how to indicate that a zip
file contains UTF-8 file and directory names. Appendix D also
describes how to identify the use encodings other than UTF-8 via the
0x0008 Extra Field.

==Extensibility==

A widget resource can be created using proprietary extensions to the
[Zip] specification so long as the resulting widget resource can be
interoperably processed across widget user agents, and are still a
valid Zip file (as defined in the section above). Zip files that
cannot be processes by other widget user agents are non-conforming and
must be treated as an invalid Zip file.

Kind regards,
Marcos

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