Dear Marcos and other WG Members,
I can see you've published another LCWD. As Anne van Kesteren wrote earlier
this month, a WD gives more incentive for feedback; I believe people tend to
think (at least subconsciously) of editors' drafts as something likely to be
used as their personal notepads where they may feel free to mess around in any
ways they like to work without being constrained by readability or other
concerns which need polishing when a document goes official (at least I do).
So I've reviewed it and here are some comments, followed by a reply to your
mail from 9th September.
Never the less, this document speaks only of a conforming specification
(defined below).
I'm not a native speaker of English, but shouldn't that be Nevertheless?
A conforming specification MUST specify how a widget user agent will process
a widget resource that was served with an unsupported MIME type
This is already fully specified in a MIME RFC, namely that it's treated as
application/octet-stream. I can imagine you'd like widget user agents to
override the MIME type in some cases. This could only be allowed with user
consent. The consent needn't be granted each time such situation arises. It can
be a configurable option of the widget user agent. You may want to make
providing this option a SHOULD. But MUST be disabled by default. I believe it's
the furthest that the Widgets spec can go.
In addition, a conforming specification SHOULD recommend that a widget
resource always contains a file extension, even when being sent over HTTP.
As you already know, neither I, nor Web architecture gurus, led by Tim
Berners-Lee, consider this a good idea. This would conflict with best practices
stated in many different places, so were it a SHOULD, I'd just blame the spec
and do otherwise. If you don't change your mind, I hope at least yit's not
going to be a MUST in the spec.
A conforming specification MUST specify a file extension for widget resources
not intended to be sent over HTTP.
Let me elaborate a bit on my point of view which I claim to be more Web-centric
than contemporary-PC-centric. Filename extensions are artifacts of many popular
tree structured file systems which usually haven't got other reliable means
(not that this one is particularly reliable, but on a local system conflicts
are more manageable than on the Web) to differentiate among content types.
(Windows experimented with some slender MIME provisions before XP but
apparently it was abandonned, unfortunately.) They are a technicality to which
users should not be exposed by default (expecting them to learn a dictionary of
mostly TLAs is commonplace but regrettable). (Some OSes feature hiding
extensions. I have it turned off because otherwise there's no simple way in
Vista to change the type of a file. As an advanced used I'd like a UI to change
the MIME type (or extension as a poor man's substitute in a MIME unaware OS),
and a not significantly less simple than to change the filename (or even just
as simple, but still separate, as the operation is conceptually distinct from
renaming). I don't know the current state on Apple systems but it used to be
similar.) Now, the ubiquity of extensions on desktops has creeped out into some
other worlds, not omitting the Web. While it's mostly harmless in some more
file-centric contexts (like FTP), newer Web standards (including HTTP) are
designed with a completely different, more robust and flexible idea. This way
it's meaningful to have default resources in HTTP directories (for URIs with
paths ending in / or bare authority). More importantly, as Tim Berners-Lee
described in his classical Cool URIs don't change, it allows authors to
replace representations of resources with ones of different types. (If you
specify Widgets 2.0 based on MIME containers, it'll have a different MIME type
(multipart/widget or something), yet there will be no need to change the URI
(which would break links to it from the Web, bookmarks, user agents' startup
settings, etc.). An extreme example (but not unlikely, given that .swf is
commonly used in URIs) would be if you had to serve your weather widget
previously written in Flash at http://example.org/weather.swf.) Of course
having two systems which aren't fully compatible (popular file systems and the
Internet) creates two points at which the incompatibilities should be dealt
with. One is saving a widget resource to your file system. It's reasonable to
expect that the user agent will offer the appropriate extension by default. The
other is when a file is published on the Web. Authors are already aware (and
much outreach and education effort has been spent on it for several years) that
this includes two most important things: minting the URI and assigning a MIME
type. Web servers have significantly improved in being easily configurable to
provide good defaults when automatically publishing files in some selected
directory tree as
