- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 26 May 2008 10:36:48 +0200
- To: Marcos Caceres <marcosscaceres@gmail.com>
- Cc: Larry Masinter <LMM@acm.org>, www-tag@w3.org, public-appformats@w3.org
On 2008-05-26 16:06:42 +1000, Marcos Caceres wrote: >> This seems reminiscent to "thismessage" scheme introduced in >> RFC 2557 as a way of supplying relative paths in a package >> – if there are never references from one widget to >> another, then why does the UUID or random number need to appear >> in the scheme? Why is there any need for an authority? > Because this may change in the future. A lot of people want > cross-widget communication but it is unlikely we will be able to > get it into the spec for version 1.0 (which we want to get to LC > by Oct). However, we need something robust enough to handle that > use case. It's not just communication across widgets, but communication across widget instances. It might very well be desirable to be able to distinguish separate instances of the same widget. > Strictly speaking, most implementations of Zip only support > cp437. UTF-8 support was only added last year (v6.3) and very few > implementations actually support it. The encoding of a file name > is dependent on magic bits in the zip archive (called the General > Purpose Bit 11 of the Local File Header): only if the bit is set > is the file name of a file entry is treated as UTF-8. > Can you please provide the questions that this raises so I can > address them in the spec? Think of the cp437 encoded file names as a particularly weird representation of the "real", unicode, string, and use the latter one in URI references. -- Thomas Roessler, W3C <tlr@w3.org>
Received on Monday, 26 May 2008 08:37:27 UTC