On Dec 1, 2007 1:52 AM, Robin Berjon <[EMAIL PROTECTED]> wrote: > On Nov 30, 2007, at 13:29, Marcos Caceres wrote: > > On Nov 30, 2007 10:14 PM, Bjoern Hoehrmann <[EMAIL PROTECTED]> 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
