An outline proposal

[Dennis E. Hamilton]

Hi Dave,

I disagree with the scope.  I think we want to limit ourselves to Zip as
packaging mechanism for documents and not Zip as a comprehensive archive
format.  We want to be compatible with such as there might be, by basing the
result on Zip, but I don't think we need to embrace all of that for our
purposes.

Think, Zip/D for documents akin to PDF/A for archives or TIFF/F for Fax.

I see no need to worry about the use of Zip as a means of software
deployment, any use to carry software-development artifacts, and any use in
conjunction with backup/restore and transport of file-system snapshots.  

I have no quarrel with your 1.1-1.2 and observe that Zip has such capability
already and it is appropriate to limiting usage to those for Zip/D.

The other requirements you list are also within the parameters for usage of
PKZip now, without need to rely on any special features.  The inclusion of a
plaintext manifest is not part of PKZip of course, and is redundant at the
basic Zip level.  (I'm not arguing against a manifest, just pointing out
that obtaining a list of the contents of a Zip package is common.)

I also think that any specification should be equivalent to a profile of
PKZip even though access to a PKZip APPNOTE should not be required to use
the specification and independently develop interoperable implementations.

The only provisions for the use of Zip as the Zip/D platform should be ones
that do not depend upon or address differences in file system organizations,
admissible naming, and interpretation of hierarchical names as paths in
folder structures.  At the same time, it should remain convenient to
construct Zip/Ds from folder structures and partial/complete extraction into
file systems should be feasible though not addressed.  I believe this is
supported by being conservative in the rules for naming parts in the Zip/D.
We also need to deal with a facet that is not part of the Use case for
PKZip, and that is ensuring resolution of URI References to the hierarchic
namings used in Zip/D.  

Beyond that minimal reliance, I think the special provisions beyond PKZip
have to do with the incorporation of multiple components as separate parts
in the Zip and how those components may be interrelated and how they may be
referenced from an agent operating external to the Zip/D.

For documents, there is need for supplemental provisions that are not
ordinary in the use of Zip as a carrier of something intended to be exported
to a file system.  This will be more difficult.

Finally, I don't think that Zip/D should be tantamount to OPC [as
established in IS 29500], although it should certainly be possible to use
Zip/D as an OPC carrier.  It is useful to observe, in this specific case,
that OPC is not Zip specific, although there is a Zip representation of OPC.
We should not do anything to break that.  I also think that there is
something important to learn about how OPC carries interdependencies among
the components external to the components themselves, so that they are
subject to inspection and interpretation without having to understand the
deeper content.  I don't think one would force this at the fundamental
level, but I can see recommending a leveling that harmonizes with this
aspect of OPC.

Afterthoughts: It might be that Zip/D0 would be the basic conventions that
apply to the package itself, without consideration of the
*document-oriented* content.  

Zip/D1 might be the minimum support for, say, a manifest and how
interdependencies and cross-references are handled within the components
along with dependencies to and from external material.  (The ability to
export RDF that makes internal relative references in a package to RDF that
can live outside of the package is a crucial condition that must be afforded
somehow.)  

The counterpart of OPC relationships might live in a Zip/D2 level.

 - Dennis

[PS: Once one starts to carry explicit dependencies as part of the packaging
model, it does raise the prospect of non-document applications involving
multiple interdependent components such as those involved in software
engineering artifacts and software deployment, for example.  I think such
use cases should be excluded from Zip/D leveling nonetheless.  Other
applications would certainly benefit from Zip/D0, for example.]



-----Original Message-----
From: sc34wg1study-bounces at vse.cz [mailto:sc34wg1study-bounces at vse.cz] On
Behalf Of Dave Pawson
Sent: Wednesday, October 13, 2010 09:20
To: ISO Zip
Subject: An outline proposal

My view,
A bare outline, skipping the 'version'/type of zip, until we get legal
input.

Comments please?

2010-10-09T21:29:51Z
Outline requirements for a zip specification.
rev 1.0, Dave Pawson

1. Provide a compressed archive format for general use.

1.1. A compression algorithm shall be provided which is usable without
infringing any existent patent.

1.2. A compression algorithm shall be provided which may be used
without payment of any sort.


2. The packaged entity shall hold one or more file.

2.1 It will be possible to extract one or more individual files from
the package.

2.2 Any file hierarchy present when the package is created shall be
duplicated on extraction if requested.

2.3 The package shall hold any combintation of  binary and/or text
files.

2.3.1 There shall be no difference between a file prior to being
archived and the corresponding file when extracted from the archive.

2.3.2 No change shall be made to any character encoding by compressing
and decompressing a file. I.e. an input file after decompression must
match its character encoding prior to compression.

3. A means of verification of an archive shall be provided.

4. A means of listing the contents of an archive without extraction
shall be provided.

5. A package listing shall be created as a a plain text file within
the archive which lists all files within the archive excepting itself.


5. A means of extracting the contents of an archive shall be provided
which meets the requirement of 2.3.1

5.1. A decompression algorithm shall be provided which is usable without
infringing any existent patent.

5.2. A decompression algorithm shall be provided which may be used
without payment of any sort.




-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
_______________________________________________
sc34wg1study mailing list
sc34wg1study at vse.cz
http://mailman.vse.cz/mailman/listinfo/sc34wg1study