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<br><br>This means finding a rougly agreed common subset that is both reasonnable and as small as necessary<br>
<br>The fact that we, or any other group, build something more complex on the top of that, at a later date, is <br>1) possible<br>2) not a problem to me<br>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)<br>
4) may take way more time<br><br><br>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.<br>
<br>PNG versus GIF is a good example in many ways :<br>* For patent reason, they took the time to make a more able standard than GIF (alpha, 24bits color, gamma correction, 2 dim interlacing, etc.)<br>* it took few years to be mainstream<br>
* GIF still exists<br><br>Regards,<br><br>Mohamed<br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 11:05 AM, Alex Brown <span dir="ltr"><<a href="mailto:alexb@griffinbrown.co.uk">alexb@griffinbrown.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Dear all,<br>
<div class="im"><br>
> Come on Alex, speak up.<br>
<br>
</div>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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 ...<br>
<br>
- Alex.<br>
<br>
<br>
<br>
______________________________________________________________________<br>
This email has been scanned by the MessageLabs Email Security System.<br>
For more information please visit <a href="http://www.messagelabs.com/email" target="_blank">http://www.messagelabs.com/email</a><br>
______________________________________________________________________<br>
<div><div></div><div class="h5">_______________________________________________<br>
sc34wg1study mailing list<br>
<a href="mailto:sc34wg1study@vse.cz">sc34wg1study@vse.cz</a><br>
<a href="http://mailman.vse.cz/mailman/listinfo/sc34wg1study" target="_blank">http://mailman.vse.cz/mailman/listinfo/sc34wg1study</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Innovimax SARL<br>Consulting, Training & XML Development<br>9, impasse des Orteaux<br>75020 Paris<br>Tel : +33 9 52 475787<br>Fax : +33 1 4356 1746<br><a href="http://www.innovimax.fr">http://www.innovimax.fr</a><br>
RCS Paris 488.018.631<br>SARL au capital de 10.000 €<br>