RE: [widgets] Widgets URI scheme

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/*).

 

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.

 

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.

 

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?

 

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 cp427 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.

 

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.

 

Larry

-- 

http://larry.masinter.net