Re: [widgets] Widgets URI scheme

On Sat, May 24, 2008 at 3:41 AM, Larry Masinter <LMM@acm.org> wrote:
> There are two pieces of web infrastructure that are in need of repair, and
> some W3C effort to improve them would help greatly: the "file:" URI scheme
> and the application/zip content-type(and, in general, packaged content-types
> based on zip rather than multipart/*).

That would be helpful.

> Many file systems and web servers already blur the distinction between a
> file directory or file system and a 'package' (whether it's called zip, jar,
> cab, UCF or something else). An update to (or, possibly replacement for)
> file: which allowed descent into packaged directories (and was well defined)
> would help out quite a bit, although it may be a little tricky to allow
> paths that are relative to 'root of the package', which seems to be wanted
> in some circumstances.

That would also be helpful.

> While fragment identifiers might be one way to identify components of
> packaged types, they don't have the richness or robustness that relative
> URIs with a package-defined root might have.
>

Agreed.

>
> Specific comments on the proposed "widget:" scheme:
>
> 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 looks like there is some attempt to deal with the difficulties of dealing
> simultaneously with localized file names and platform-independent localized
> names, but the appearance of cp437 as the sole alternative character
> encoding and the lack of any explanation for how file system ambiguities are
> to be resolved just raises lots of questions.
>

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?

>
> URI schemes should either specified as URIs with restriction to characters
> allowed in URIs (which doesn't include many of the characters allowed in the
> proposed specification), or as IRIs with the standard IRI -> URI
> transformation of UTF-8 encoding followed by hex-encoding. The specification
> doesn't take either path, which results in something that would be
> unacceptable to many URI processors.

Good point. I'll make sure that spec only talks about IRIs.

-- 
Marcos Caceres
http://datadriven.com.au

Received on Monday, 26 May 2008 06:07:29 UTC