- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Mon, 3 Dec 2007 11:35:14 +1000
- To: "Robin Berjon" <robin@berjon.com>
- Cc: www-international@w3.org, "public-appformats@w3.org (public)" <public-appformats@w3.org>
On Dec 1, 2007 1:52 AM, Robin Berjon <robin@berjon.com> wrote: > On Nov 30, 2007, at 13:29, Marcos Caceres wrote: > > On Nov 30, 2007 10:14 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > >> This is really an issue with the "ZIP" specification and deployed > >> soft- > >> ware, not with the "Widgets" specification. It does not seem > >> useful to > >> say anything about this in the Widgets specification beyond saying > >> the > >> archive should be created in accordance with the ZIP specification > >> and > >> that there may be interoperability issues with using non-ASCII names, > >> so those should be avoided, which should be quite normal for authors. > > > > I'm totally ok with doing that... I guess as long as it won't raise > > any issues later because we didn't really provide a solution to the > > problem. Would this be ok with the i18n community? (ie. make it > > Zip/implementer's problem) . > > The I18N community is, by definition, pretty much all of us ;-) More > seriously, in general and as a rule of thumb it's a bad idea for one > specification to try an address issues present in another. It's an > almost sure-fire way of creating incompatibilities and animosity down > the line. Agreed. The issues are not so much in the Zip spec, more in that some vendors took a bit of liberty with their Zip implementations (eg. MacOs encoding names in UTF-8, and Java encoding with Modified UTF-8, etc). > The only exception to this rule is of course if you're for instance > the CDF WG or the TAG, in which case you should regularly threaten to > solve other people's issues so that, in awed fear that you might > actually do it, they get to work. :) -- Marcos Caceres http://datadriven.com.au
Received on Monday, 3 December 2007 01:35:21 UTC