An outline proposal
dave.pawson at gmail.com
Fri Oct 15 08:48:10 CEST 2010
On 15 October 2010 03:28, Dennis E. Hamilton <dennis.hamilton at acm.org> wrote:
> Personally, I think standardizing a fully-specified, independently usable
> *subset* of Zip would be fine, with the proviso that it really be a subset
> and that packages created with it would be fully acceptable as Zip packages.
For which please define 'zip'?
> To try for a full Zip and embrace the incredible variability of Zip, even to
> the degree it is specified in APPNOTE 6.2.0 strikes me as madness.
As well as being encumbered? Is that workable across Windows, Mac, Linux?
> Of course, IS 26300 profiles APPNOTE 6.2.0 now, and ODF 1.2 could do
> something similar, such that we would be indifferent to any full-Zip
> standardization at the ISO level so long as there was enough compatibility
which raises the obvious question Dennis?
> More troublesome would be any composite-document structure grafted onto
> packages as part of integrating with Zip but that don't have any impact on
> Zip itself. It is any effort in this area that would arouse the attention
> of the ODF TC and, I presume, ECMA, SC34 WG4, and others. The original NWI
> proposal had such considerations in its scope with regard to inter-component
> references within the package and potentially package-outbound and -inbound
> as well. If that is determined to be out-of-scope, we can also go home
Had we a scope (real, rather than imagined) I could answer that Dennis.
Note that the expath work is just now considering 'which' zip, i.e. all their
work may rise 'above' an implementation.
>> 2) Can we handle JAR/WAR/EAR ?
>> 3) Can we handle Widget ?
As those are ZIP files, yes, we should be able to read them.
At the ZIP layer level of course (nothing specific to JAR files
or widgets themselves). But this is both interesting use cases.
Validating that we can support all options in the JAR and Widget
specs is an interesting indicator (e.g. the signing stuff).
It will be interested to see which way they go.
XSLT XSL-FO FAQ.
More information about the sc34wg1study