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 resources. Summing up, not having extensions is desirable on
the Web in general, not only in HTTP, and outside the Web it's just one (albeit
popular) way to store metadata about content types (if done this way, a mapping
to MIME is a desirable feature, and that should be exposed to users instead of
the extensions). So here's my suggested wording:
--
A conforming specification MUST specify a filename extension which should be
used for widget resources in contexts that rely on extensions, such as many
popular file systems.
--
But do you actually need to write it explicitly? The rule is already applicable
with IANA registration (you map MIME your type to an extension, but uniqueness
isn't indispensable) which is required in R2.
> To disable access by widget instances to the underlying file system (if any)
> or other resources which are not instances of the same widget
You still want to be able to communicate with other widgets, right? (So do I,
naturally. :-)) So addressing them must be possible (maybe with some other
scheme, but I don't think you'll end up with two significantly different ones;
addressing instances of widgets, be them instantiated from the same resource or
another, is enough of a challenge to be solved in just one way). Please clarify
that "access" in the above is something more than addressing. I suggest "access
for potentially unsafe manipulation".
> 'resources/en-au/'
If it's a language tag between "/"s, the canonical capitalization is "en-AU",
so I suggest changing this. Also note that language tags are case-insensitive
by themselves but many URI schemes (including http:) are case-sensitive.
> Device Independence Delivery
Did you mean "independent"? (I did when suggesting. ;-))
> <dfn id="format"><abbr title="Extensible Markup Language">Format</abbr> and
> Schema</dfn>
Still mentions XML.
> The schema SHOULD NOT be a normative part of the conforming specification
Why is that?
> A conforming specification MUST specify graceful error handling procedures
> for all metadata elements
Once you wrote these were XML elements. It seems to be no longer necessarily
the case. How about "metadata items"? Even with XML I'd tend to referring to
something as syntactic as elements here.
> or contradictory to the system
What does it mean?
> or declared erroneously by an author
This is mentioned separately from just being in error. Again, what does it mean?
> A conforming specification MUST specify the structure and semantics of
> elements that represent data
No XML assumption, right? Consider dropping "elements that represent".
> A conforming specification MUST specify that styling by the author takes
> precedence
Do you disagree with my point that user style sheets should also apply? You
didn't write anything about it.
> HTTP(S)
May be mentioned but please don't recommend it. The existence of https:
violates the Web architecture.
> policy which exists to represent the end user (or the owner of the device)
Not necessarily the owner, I believe. May I use my friend's handheld device? Or
a scenario whereby the device only has input and output functionality and the
actual execution (possibly for multiple such clients) takes place on some more
powerful system (like a company's mainframe)?
> There are other WGs working on this requirements
Plural or singular?
> Ajax
Don't you capitalize this acronym?
> A conforming specification SHOULD specify a means that allows authors to open
> IRIs in a browsing context outside the widget user agent.
It may be the same agent. I imagine a typical Web browser should just use
another tab. My suggestion: "in a new browsing context" period.
> make widget user agents interoperate more effectively with each other and
> with Web services.
The term Web services is already reserved for something else than you mean
here, especially in W3C.
> where the widget user agent can be check for updates
s/check/checked
> HTML
Why is this reference normative?
R40 is not in 4.6, R26 and R39 are similar but the small difference seems
unrelated to the difference between headings of their sections. Please consider
rearranging the chapter.
> Having said that, I have also changed the requirement on the
> configuration format mandating the use of XML because that is also
> being overly prescriptive.
It was my impression too, so definitely.
> I guess it's a matter of proactive participation from the
> MIME-supporting community.
Well, most if not all of the "high priesthood" would subscribe to this
community and claim MIME's universal applicability should be taken for granted
whenever features with which it was designed are desirable. But you know their
manner, they don't act like, say, the microformats community.
> you are the first person who has really stopped the
> Working Group and said "hey! what about MIME???"
The MIME-supporting community from time to time makes some comments about what
they believe (and they're right) MIME can provide to resolve some problem
actively pursued bu others that reaches their attention. A few of them can be
found in this list's archives. I can't claim the honour of being the first to
have made one.
> As we go forward, I
> also think MIME needs consideration, but at the same time why don't we
> push of PKWare to finally standardize Zip and integrate the advance
> MIME stuff into Zip? Zip is more widely deployed then MIME and is
> there really any reason why features can't be added to Zip to make it
> do what (advanced) MIME provides?
That would be retrofitting and I don't imagine any result other than an
artificial one. ZIP is primarily for compression. It's got a packaging
functionality (to encapsulate a tree structure of multiple files, part of a
typical file system) but it's superimposed and rather limited (no rich metadata
in particular, which would allow for labelling files with MIME types without
resorting to an external mapping I suggested). MIME has quite the opposite. Its
multipart type is meant to serve as generic containers fully equipped with
features desirable on the Internet. One of them is optional compression with
any specified format (gzip and deflate are most common, I think) and any
granularity.
> In your
> example, the MIME type is not the correct so processing would fail for
> that resource (unless sniffing takes place on the SVG file or it
> actually is an audio clip).
Well, maybe that will tell you something about the Web science (cool new term,
isn't it? ;-)) way of thinking. When I wrote my example it was obvious to me
that x.svg actually contanined an audio clip. Were I to include an invalid
example, I'd most probably warn of it. My point in many of our arguments is
that graceful catering for invalid cases can be a noble goal only as long as it
doesn't blow up in the face of people who do the right thing instead. (Note:
the example wasn't 100% the right thing because of an uncool URI, as I
mentioned, but certainly it was valid. I can legitimately put an audio/basic
resource at any http: URI under my control. And expect the rest wishing to
interact to obey Web architectural rules because I obeyed them for my part.)
> Understood. Like I said, we only need sniffing for when resources are
> received from sources other than the web. When a WUA is getting a
> widget from the web, it should follow standard MIME style processing.
Very well, glad to read it stated explicitly. How is that in scope then? This
would be the first W3C spec going to extra lengths to ensure interoperability
outside the Web. You may claim it serves the Web to have broader
interoperability and I do sympathize with this but I think for W3C to maintain
its well established and clearly perceived position there cannot be any MUSTs
on what happens elsewhere, at most SHOULDs.
Only one correction though, if I may: MIME is used in some offline contexts and
should be respected there as well. On the other hand, although it's bad
practice, a WUA might come across a resource without a MIME type on the Web
(and on the Internet more generally). It's perfectly legal not to mention at
all sniffing, which is allowed in such cases (and only then, on the Internet at
least), indeed all existing specs I know leave this entirely to implementors,
but I bet you wouldn't like to miss this opportunity.
I'll restate one of my questions. Could you list in one place the technologies
with existing standards you considered for R26? There seems to be no record in
the list archives.
> However, I personally think that it is romantic to say that HTML on
> its own can truly meet this requirement
Why not? (X)HTML is designed with accessibility in mind, applies the tenet of
separation of concerns (semantics from presentation), as a result it's not only
media independent but even presentation agnostic (meaning that you could well
have (X)HTML documents not intended for being rendered to users at all, e.g. as
a back-end archiving format or intermediate step in a processing pipeline). Of
course it gets horribly misused by many. And the success of providing a
reasonably good toolset specifically for styling (CSS) has so far led to quite
limited improvements of authors' practices in architectural terms (mostly
because of an overwhelming number of bugs in browsers and authoring tools, but
that's a subject for another conversation).
Best regards,
Chris
