Re: Comments on Widgets 1.0: Requirements LCWD

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 <1981km@gmail.com>:
> 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 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.
> --

Agreed, agreed, and more agreed... and I we have the same position of
the subject (thankfully you are much more articulate than I). I've
used your recommended text.

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

Yes, but the intention is just to reinforce to the world know that we
intend to use ".wgt" and to let user agents know to treat the file
extension as case insensitive, etc. More details about this are in the
actual packaging spec.

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

Agreed. Added your recommended text.

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

Ok, changed it.

>> Device Independence Delivery
> Did you mean "independent"? (I did when suggesting. ;-))
>

Woops! fixed.

>> <dfn id="format"><abbr title="Extensible Markup Language">Format</abbr> and Schema</dfn>
> Still mentions XML.
>

Well spotted:) Fixed.

>> The schema SHOULD NOT be a normative part of the conforming specification
> Why is that?
>

Mainly because it is possible to create crap markup and for it to
still be valid. We are not saying "don't validate" and we encourage
the creation of validation tools. In fact, we've spoken to Henri
Sivonen about adding Widget config file validation to validator.nu. We
are trying to emphasise to authors (and I guess to the W3C) that valid
markup does not correlate to good use of markup and that no schema
langauge exists that can capture the intricacies required to fully
validate the configuration document correctly.

>> 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?
>

Contradictory to the system meant using a capability or something that
is not available or would break the widget widget engine. For
instance, declaring that a widget's width be 1000000 times wider than
the size of the display. However, I agree that "contradictory to the
system" is convoluted. Any suggestion of what I might change it to?

>> or declared erroneously by an author
> This is mentioned separately from just being in error. Again, what does it mean?
>

What I meant to say here is that an author can, for instance, do this
: <widget width="100-20"/>. I guess that is an error, but I'm just
trying to say that the author should not be punished. Should I just
drop that bit of the statement?

>> A conforming specification MUST specify the structure and semantics of elements that represent data
> No XML assumption, right? Consider dropping "elements that represent".
>

Dropped.

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

Sorry, I seemed to have missed that in the original email. I certainly
don't disagree. How does this sound?:

"For widgets that make use of a rendering context, a conforming
specification SHOULD specify an OPTIONAL means for an author to
declare the initial visual dimensions for an instantiated widget in a
way that is device independent (e.g. via CSS pixels). In the absence
of user style sheets, a conforming specification MUST specify that
styling by the author takes precedence over dimensional values
declared in the configuration document or any dimensional values
implicitly computed by the widget user agent. However, in the presence
of user style sheets, user style sheets take precedence but MUST be
applied in conformance to the cascade model and rules of behavior
specified in CSS2.1."

>> HTTP(S)
> May be mentioned but please don't recommend it. The existence of https: violates the Web architecture.
>

Ok. I said instead "...declarations to be securely acquired from an
external trusted authority over HTTP".... Hence, implying HTTPS or
some authenticated means.

>> 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?
>

Singular, fixed.

>> Ajax
> Don't you capitalize this acronym?
>

We prefer not to use Ajax as an acronym... as it makes no sense as an
acronym. Even Garrett agrees [1], "I thought of Ajax as a convenient
[term]. It was never intended as an 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.
>

Done.

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

Understood. Changed it to "services on the Web".

>> where the widget user agent can be check for updates
> s/check/checked
>

Fixed (dropped "be")

>> HTML
> Why is this reference normative?
>

Because of R36 (langauge accessibility).... I renamed r36. to "User
Interface Accessibility", which I think convey the intent more
clearly.

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

R40 is now in 4.6.

You are right, I merged R39 into R26.

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

great.

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

Ok. I see your point. However, I'm not sure what I can do as vendors
won't budge on this issue for now.  At the moment, ZIP serves the
purpose for widgets. But as they become more popular, the limitations
with Zip will quickly be exposed. Zip will either have to become more
like MIME or we will have to migrate over to MIME... we will seriously
need to watch the evolution of Widgets and the market in regards to
this.

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

agreed.

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

We don't want to be accused on not having covered the case that was
obviously going to come up in practice (dealing with a resource
without a MIME). For me, it's not a big deal to specify it... even it
the spec says treat it as invalid.

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

I can't list them off the top of my head, but pleas see the
"[widgets] Widgets URI scheme" thread here:
http://lists.w3.org/Archives/Public/www-tag/2008May/subject.html

And see also:
http://lists.w3.org/Archives/Public/www-tag/2008Aug/0121.html

We basically evaluated all the different packaging formats (and URI
schemes) that people suggested. Admittedly it was very few because we
knew it either had to be MIME or Zip (the current de facto standard).

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

Ok; yes, "simple" HTML pages can be authored to be accessible. More
complex Web applications, like Google Reader, need a little more (like
ARIA). So what I meant was the HTML has to be enhanced in order to
meet the accessibility requirements that users have come to expect
from today's Web.

[1] http://www.gcn.com/blogs/tech/41547.html

-- 
Marcos Caceres
http://datadriven.com.au

Received on Monday, 22 September 2008 16:41:44 UTC