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

Hi Marcos,
Overall, I think this is a good direction. It sets the bar about as low as
possible for both consumers and producers, allows the use of existing tools
(Windows built-in ZIP tools, WinZip, etc.), with while still defining what
it means to be interoperable, allows OOXML to embed all of the
Windows-specific extension fields, and the specification is short and
understandable.

The ideal approach from a standards perspective would be to separate out
the ZIP writeup into a separate standalone spec (i.e., don't reference the
OCF spec, just "repurpose" its technical approaches) so that it can be
reused by other initiatives (W3C or otherwise). When I was involved in the
OCF spec, the IDPF folks were amenable to updating their eBook specs to
point to an official standard packaging standard from other standards
bodies, where W3C and OASIS were the presumed likely choices, and W3C was
the top preference. Maybe the next version of ODF would reference such a
W3C standard. I am pretty sure they would conclude it's the right thing to
do.

I haven't had time to think through the UTF-8 issues. A minor red flag is
raised when I see the word "MAY". Are you saying it is OK to use
platform-native encodings, Shift-JIS encoding or (showing my age) EBCDIC
encodings? Maybe there is an encoding field in the ZIP spec. (If I ever
knew about this field, I have forgotten it by now.) Remember, the goal of
standards are to promote interoperability, and if file name encodings are a
free-for-all, then interoperability might suffer.

Regarding the issue of proprietary extensions, how about just staying
silent on the issue? Basically, the above OCF-like approach is a
whitelisting approach which identifies the fields that producers and
consumers must support. Other fields, whether define in the ZIP spec or
extensions defined by vendors, can be ignored by the consumer. For example,
there isn't a problem with MS (for example) extending ZIP to make the
format do special magic on Windows so long as the resulting ZIP file will
still open with non-MS software (e.g., WinZip) and continue to work on Mac
and Linux systems.

Jon





                                                                           
             "Marcos Caceres"                                              
             <marcosscaceres@g                                             
             mail.com>                                                  To 
             Sent by:                  "public-appformats@w3.org"          
             public-appformats         <public-appformats@w3.org>          
             -request@w3.org                                            cc 
                                       Jon Ferraiolo/Menlo Park/IBM@IBMUS  
                                                                   Subject 
             10/05/2007 12:04          Re: [WIDGETS] Zip Support (request  
             AM                        for comments)                       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Ok, here is some draft text if we were to go down the OCF route for
Zip. The only bit I would change is to relax and clarify the UTF-8
conformance requirement in OCF. I've also now allowed Zip64.

=Zip files=

For the purposes of this specification, A valid Zip file is a data
object that conforms to the production of a Zip Container as defined
in Section 4 of the [OCF] specification. In the event that a widget
user agents encounters 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:

As with [OCF], 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.

As with [OCF], Zip files must be created using the Deflate compression
algorithm as specified in the [Zip] specification. 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.

As with [OCF], A Zip file may be created using the ZIP64 extensions
defined in [Zip].

As with [OCF], 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 should be encoded
in US-ASCII within the valid range of characters for file and
directory names (defined elsewhere).

As with [OCF], the names of files and directories within a Zip file
may be encoded in UTF-8 but only in conformance with Section 3.3 (File
Names) of the [OCF] specification. A widget user agent must treat Zip
files that don't conform to Section 3.3 of the [OCF] specification as
being in error.

Note: Please also 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 names.

Issue: Using proprietary extensions to the [Zip] specification makes a
widget resource non-conforming.

Kind regards,

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