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:
> 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. > 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.) 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? > 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". > : <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. > 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.
