Re: LINK TYPE=override/type

Ian Graham (igraham@smaug.java.utoronto.ca)
Fri, 23 Jan 1998 10:43:52 -0500 (EST)


From: igraham@smaug.java.utoronto.ca (Ian Graham)
Message-Id: <199801231543.KAA15677@smaug.java.utoronto.ca>
To: bereza@pobox.com (Bill Bereza)
Date: Fri, 23 Jan 1998 10:43:52 -0500 (EST)
Cc: www-html@w3.org
In-Reply-To: <Pine.SUN.3.96.980123010746.5904A-100000@galileo.cris.com> from "Bill Bereza" at Jan 23, 98 01:16:16 am
Subject: Re: LINK TYPE=override/type

Bill Wrote: 
> On Thu, 22 Jan 1998, Ian Graham wrote:
> 
> > This assumes that you can self-consistently manage all linked documents,
> > which is not the case.  For example, someone linking to your document might 
> > specify the type of your document using TYPE. But, if you subseqently 
> > change the type, their documents will break.   
> > 
> 
> I think that if you're going to be changing the MIME type of documents
> you're bound to have problems whether or not someone was using TYPE.

I do not see this. The essence of a whole variety of implemented
and proposed content delivery models (e.g., content-negotiation) requires 
that the browser and server be able to effectively negotiate a MIME type
(and other content-related properties) for a resource -- for example, you 
can use a URL that reference /path/file and have the server return different 
resources (english, german, HTML, PDF, GIF, JPEG, etc.) depending on a set 
of browser preferences.  It is the *browser's* job to handle whatever it is 
delivered, and it is the *browser's* responsibility to be able to negotiate, 
using the given protocol, for the type of the resource it wants. 

> > 
> > At the same time, I believe TYPE should play a role in error handling 
> > -- for example, if the HTTP-specified type seems to be in error, then 
> > the browser could fall back to the TYPE-specified value, and see if that
> > works. And if that doesn't work, the browser could try heuristics on the
> > file, to try and determine the correct type (i.e. ... guess!)
> > 
> 
> No, a browser can not ever do this, because there is no way for a
> browser to know or guess if a server is mis-configured. Any browser that
> tries something like that is going to mess things up very much.

I think I wasn't clear. What I am saying is that the browser should first assume
that the MIME type within the HTTP message is correct.  Should this result in 
an error in processing the data, then the browser could try assuming the TYPE
specified by the TYPE attribute of the element that referenced this resource.
IF that results in an error, it could assume some other heuristic (file suffix
mappings, parse the first 128 bytes and try and type the data, etc.) to determine
the type.  This is, for example, how many current browsers determine the
character set encoding used within a document.

Ian