An outline proposal

[Innovimax SARL]

The minimum to declare victory, as a representative of  the W3C here, is to
have a subset of what an average ZIP library can generate

This means finding a rougly agreed common subset that is both reasonnable
and as small as necessary

The fact that we, or any other group, build something more complex on the
top of that, at a later date, is
1) possible
2) not a problem to me
3) not a simple task (since if no tools implement that, it would give no
benefits see the history of CSS 2.0 on top of CSS 1.0 for a good example)
4) may take way more time


I would say to spot that in perspective that I see that as an alternative to
something way more radical : replace ZIP by something else that everyone
could agree on as a more flexible and powerful layer to package xml and any
related files.

PNG versus GIF is a good example in many ways :
* For patent reason, they took the time to make a more able standard than
GIF (alpha, 24bits color, gamma correction, 2 dim interlacing, etc.)
*  it took few years to be mainstream
* GIF still exists

Regards,

Mohamed

On Thu, Oct 14, 2010 at 11:05 AM, Alex Brown <alexb at griffinbrown.co.uk>wrote:

> Dear all,
>
> > Come on Alex, speak up.
>
> Well it's a good question: are we proposing to standardize something which
> just meets the immediate needs of format designers, or Zip-the-technology as
> a general purpose archiving technology? Or are we (as Rob suggests)
> effectively going to propose doing both by standardizing different levels of
> Zip.
>
> The original proposal that failed its ballot very much focussed on a
> "minimal" Zip that would work as a drop-in replacement for the file formats
> in which SC 34 is most interested: 26300, 29500, EPUB and W3C Widgets. Part
> of the thinking behind that was that we wanted to avoid accusations of doing
> a "land grab" or of trying to appropriate PKWare's technology. However,
> there was some worry in the ballot responses that by standardizing something
> that was not Zip, we would be risking incompatibility.
>
> I would observe that the immediate problem faced by SC 34 is the question
> of how to reference a non-standard technology (the subset of Zip used by
> e.g. OOXML) in a way which is in accord with the JTC 1 referencing rules. We
> are hearing from our liaison in W3C and our contacts in IDPF that a standard
> version of Zip would be a useful thing for them too. So it seems to me the
> need for at least a minimal Zip is established -- that is after all why this
> study period is happening rather than the whole idea having been abandoned.
>
> What is less certain is whether there's a requirement for standardizing
> Zip-in-its-entirety. Participants in this group need to speak up based on
> what they are hearing from the communities they represent. Or perhaps
> another useful way to pose the question (this being a consensus-based
> process) is: are there OBJECTIONS to such an effort? Or maybe a longer-term
> compromise approach might be standardize a base-level Zip now, without
> precluding the possibility that it might be extended to become a more
> fully-featured Zip at a later date ...
>
> - Alex.
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> _______________________________________________
> sc34wg1study mailing list
> sc34wg1study at vse.cz
> http://mailman.vse.cz/mailman/listinfo/sc34wg1study
>



-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg1study/attachments/20101015/1d86bed5/attachment.htm>