An outline proposal

[Dave Pawson]

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
> format.

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.

NU.


>
> 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?


>
> Zip/D1

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
> somehow.)

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 :-)


regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk