Re: Bad practice: Overriding HTTP content-type with a URI reference

Hello Tim,

Thanks for bringing this up.

First some background, you mention SMIL:

For SMIL2, the bad practice is indeed in the spec
http://www.w3.org/TR/smil20/extended-media-object.html#adef-media-type.

For SMIL1, I haven't found anything on priority, except the following
http://www.w3.org/TR/REC-smil/#media-object:
When playing back a media object, the player must not derive the exact type 
of the media object from the name of the media object element. Instead, it 
must rely solely on other sources about the type, such as type information 
contained in the "type" attribute, or the type information communicated by 
a server or the operating system.


For SGRS, I have strongly questioned this bad practice. I think that if
every WG affected would invest just a little bit of time, it would be
very easy to improve the situation with respect to server implementations
and ISPs/webmasters. See e.g. at the end of
http://lists.w3.org/Archives/Public/www-voice/2002JanMar/0119.html.
Most WGs, and the W3C overall, have good contacts to server implementers.
This is also of relevance to I18N, because correct setting of the 'charset'
parameter of the MIME type is one of the most basic concerns for I18N in 
practice.
But for MIME types (as opposed to 'charset'), it's much easier because
of file extensions.

You say 'counter to architecture', and this is particularly well visible
in the following example. Speach recognition grammars come by definition
in two variants, an ABNF variant and an XML-based variant. One proposed
text for the spec contained the following:

http://lists.w3.org/Archives/Public/www-voice/2002AprJun/0040.html
 >>>>>>>>
** Informative: use of the type attribute should be considered a last 
resort. For
instance, the type may be appropriate when a grammar is fetched via HTTP but
(1) a web server cannot be configured to indicate the correct media type, and
(2) the grammar processor is unable to automatically detect the media type. In
the event that a grammar is transformed to another form (e.g. ABNF Form to XML
Form) then any type attribute on a reference to that grammar also must be 
modified.
 >>>>>>>

The last sentence is the one that shows that this can't work.
The idea that you can change all the links to a certain resource
is 180 degrees counter to the way the Web works.

Regards,    Martin.




At 19:08 02/06/14 -0400, Tim Berners-Lee wrote:

>In the last call working draft of SGRS,
>http://www.w3.org/TR/speech-grammar/#S2.2.2
>a reference to another document can specify the content type of the 
>destination object in a way that overrides any content-type provided by 
>the HTTP server . The same was true  of (svg? smil?).  I understand that 
>the intent was specifically to be able to reference a lot of existing data 
>in legacy (probably unregistered) mime types.
>
>This is obviously counter to the architecture, but meets a real need
>in practice for servers which just can't be configured by the people
>who publish on them.  This is fact a social/tools mess - if the
>config files took local directory input then all would be well.
>
>Maybe a compromise is to only allow the link to specify the
>content-type when the server is FTP (or something else
>with no content-type control) or the HTTP server returns
>text/plain or octet-steam, which seem to be used for
>"don't know" types.
>
>It is of course consistent to indicate "the contents of this document 
>expressed in whatever language but then reinterpreted as 
>application/whatever" but in practice such references are kludges and 
>would for example make the introduction of new versions of 
>application/whatever more difficult.
>
>Tim

Received on Tuesday, 18 June 2002 10:35:56 UTC