Hi, Krzysztof.
Thanks again for this third round feedback. Some minor things I would
like your approval on below.
2008/9/20 Krzysztof Maczyński [EMAIL PROTECTED]:
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?
Fixed.
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.
Maybe. But if vendors are going to do sniffing, then we might as well
define an interoperable model for that.
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.
Ok, I think we have been misunderstanding each other. I agree 100%
with what you are saying, so I am relaxing this to a MAY. However,
please understand that they reason we want file extensions is because
widget are shared over communication channels other than HTTP. It's
like the situation when a Mac user sends Windows users a file without
a file extension... it can lead t o a lot of frustration, which want
to avoid (more below).
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
