An outline proposal
dave.pawson at gmail.com
Wed Oct 13 20:07:18 CEST 2010
Answering the bits I understand:
On 13 October 2010 18:32, Dennis E. Hamilton <dennis.hamilton at acm.org> wrote:
> 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
I haven't scoped the work. Have you... inferred a scope?
I'm thinking of a packaging mechanism (which is how I see zip).
> 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 didn't mention any of these? I didn't constrain zipped content,
I didn't mention backup and restore or transport. How it's used
is (AFAIK) out of scope.
> 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.
I don't want to discuss 'how' until we know the ISO position wrt patents etc.
> The other requirements you list are also within the parameters for usage of
> PKZip now, without need to rely on any special features.
I didn't mention special features, you don't define them so I can't
answer that one.
The inclusion of a
> plaintext manifest is not part of PKZip of course, and is redundant at the
> basic Zip level.
I'm saying that any zip compliant to this spec has an included file
(included in the same way as any other, perhaps given a fixed name
as per jar) which provides the manifest. Lack of one can cause problems.
How implementations do it, out of scope IMHO.
> 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.
Back to implementation again. Later please, once we have a good requirement.
> 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.
Would you like to include such in the requirement?
I can see lots of gotcha's there.
All I said was a file hierarchy? No mention of organisation of the files.
Do you see that as wrong?
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.
How and where extracted is out of scope IMHO
I believe this is
> supported by being conservative in the rules for naming parts in the Zip/D.
Would you expand on that please? What rules? What naming conventions?
> 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.
Not understood at all.
> Beyond that minimal reliance, I think the special provisions beyond PKZip
Implementation? Later please.
> 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.
Would you state that as a requirement please?
> Finally, I don't think that Zip/D should be tantamount to OPC [as
> established in IS 29500],
Out of scope? What's OPC? How does it affect this work?
> 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.
I haven't mentioned any orientation Dennis? Just that we should
be able to carry binary or text files?
What the heck are all these Dn's?
might be the minimum support for, say, a manifest and how
> interdependencies and cross-references are handled within the components
What interdependencies? What x-refs?
> 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
IMHO that's you 'using' a package, hence out of scope?
> [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.
Again, usage? Hence IMHO out of scope? Ditto any x-refs are usage.
I think such
> use cases should be excluded from Zip/D leveling nonetheless. Other
> applications would certainly benefit from Zip/D0, for example.]
Whatever Zip/D ... is :-)
XSLT XSL-FO FAQ.
More information about the sc34wg1study