Re: Comments on Widgets 1.0: Requirements LCWD

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

Received on Saturday, 20 September 2008 22:25:01 UTC