Re: Comments on Widgets 1.0: Requirements LCWD

Hi Krzysztof,

2008/11/3 Krzysztof Maczyński <1981km@gmail.com>:
> Marcos,
>
> Sorry for the delay in replying. When you wrote to me on 14 October, I was in the Near East with very occasional Internet access. I'll understand if at this moment it's to late to give my input the full weight in your process it could have had if sent earlier. Anyway, here it goes:
>

No pros. Apologies on my part too, I've also been away on vacation for
the last 3 week.

>> 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).
> Yes, I understand this issue and I believe I have already treated it previously. But I'll try to restate my thoughts with a concrete example. The resource, when stored as a file on a file system supporting extensions as the way of indicating content types (or in some other context where using extensions in this way is the standard practice), should indeed be named with an appropriate extension. But that is a consideration principally outside the Web. I wrote that it needn't be mentioned, but if mentioning is deemed desirable, no normative specification language should apply (ideally no MUST, SHOULD, MAY or their RFC 2119 relatives). For example, assume you have a Linux system with a file ~/public_html/MyWidget.widget and you decide to publish it on the Web with HTTP. Then the default thing to do for your Web server may be to create a resource under the URI http://MyDomain.example.org/MyWidget whose representation will be the content of this file and which will be served with an appropriate Content-Type header. Conversely, if a Windows user downloads this resource and saves it on his file system, the user agent performing this (e.g. a download manager which follows Web usage of MIME and can access a mapping from MIME types to extensions registered in Windows (maintained by itself, by the default Web browser, by the browser for which the download manager is a plugin, or wherever else)) may add an appropriate extension automatically or include it as the default if the user is prompted for the file name.
>

Your last sentence captures the intention of the usage of the file
extension precisely. However, it is not a guarantee that a user agent
will know what extension to apply based on the MIME type. To this
effect, the spec will still  "recommended" that the extension be
".wgt" (if only to guide authors for these exceptional circumstances -
and completely unrelated to the world of HTTP). We by no means want to
violate the TAG findings or to mandate that the file extension always
be present, but we need to do our best to ensure interop once widgets
leave the Web. I don't know of any other way of reducing the file
extension interop problem in the spec, but to recommend the file
extension and the appropriate content-type sniffing behaviors for UAs.

The requirement is now simply:

"A conforming specification MUST specify a file name extension that
authors MAY assign to widget resources in contexts that rely on file
extensions, such as many popular file systems."

So, it is now silent on any HTTP related matter.

In the rationale, I used some of your text (last sentence):

"When a MIME Type is not present, as is the case when a widget is
instantiated locally from an end-user's storage device, the operating
system will sometimes use the file extension to associate the widget
resource with the appropriate widget user agent. However, when the
widget is distributed over HTTP and a MIME type is present, a file
extension is not required. However, it should be noted that in some
cases a Web server may rely on a file extension to correctly set a
widget resource's MIME type in the HTTP headers. In addition, when
saving a widget to a storage device, a user agent that is aware of the
content type of widgets could add the appropriate file extension
automatically or include it as the default if the user is prompted for
the file name."

>> no schema
>> langauge exists that can capture the intricacies required to fully
>> validate the configuration document correctly.
> I think you may mean "assert conformance of" instead of "validate". Then this is a common situation with other specifications as well (yours for the configuration document seems to be going to be relatively simple, so maybe what you've written will turn out not to be even the case), especially those which have much to do with users. (There has been much effort to significantly reduce this phenomenon in WCAG 2.0, but it would be futile to try to eliminate it.)
>

Agreed.

> However, the entire idea behind this paragraph seems surprising, to say the least. Why write a schema, which is a machine-readable version of mostly the same rules which are described in prose, with precise semantics specifically crafted by authors of the schema language to facilitate expressing such rules, and then not include it as normative?
>

As I argued in my previous email, I think because schema and
validation misleads authors (this is evident in XHTML, where one's
markup can be complete crap but totally valid; hence devaluing
validation as a whole). I agree that parts of the validation process
can be mechanized (eg. don't put tag x inside tag y), but the
conformance/validity of content within a tag usually cannot usually be
checked by a machine. And that is where the real problems with
validation begin (eg. <p>I'm a heading, realy!</p> or, in the case of
widgets, <author>da plane! da plane!</author>). Sure, it is a
politically biased decision to not make the schema normative; I'll be
the first to admit that! But it can be easily shown that the RelaxNG
schema for widgets does not fully express the prose or the parsing
algorithm. If it did, then we write the spec in a schema langauge and
not in prose.

Regardless of the normative or informative status of the schema, it
will still be part of the spec and will receive as much attention as
all other aspects in terms of quality. Conformance checkers and
authoring tools will be encouraged to make use to the schema.

>> However, I agree that "contradictory to the
>> system" is convoluted. Any suggestion of what I might change it to?
> I'd probably go for "unfeasible [for the user agent]" or "unfeasible {maybe "impossible"} to realize {maybe "satisfy" or "satisfy (realize)" or "satisfy or realize"} by the widget user agent".
>

I went with "impossible to satisfy or realize by the user agent"

>> : <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?
> Yes, I believe so. It suggests being erroneously declared is some definite condition distinguished from being in error.
>

Dropped.

>> HTML has to be enhanced in order to
>> meet the accessibility requirements
> The problem is not with HTML but with scripts. And almost none of them (particularly all written in ECMAScript et al.) would work but for the assumption (nowhere specified, pending Window Object 1.0's progress to Rec) that the global object implements the AbstractView interface (which includes the crucially important document property). But I feel this is already far enough from the present topic.
>

Agreed. Thank you again for your feedback.

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

Received on Sunday, 23 November 2008 10:40:59 UTC