Re: Format Negociation in Practice [Was: Versioning HTML at the server]

Earl Hood (ehood@imagine.convex.com)
Wed, 19 Oct 1994 02:41:40 +0100

>
> "Daniel W. Connolly" <connolly@hal.com> wrote:
>
> > It would be great if we could hash this out once and for all, and
> > deploy the solution.
>

> How about parameters on the Accept: header?
>
> User-Agent: NCSA-Mosaic/2.5
> Accept: image/gif, image/jpeg,
> text/html; tables=yes; forms=yes; images=yes,
> audio/basic
>
> (I *think* that's the right semicolon/comma precedence.)
>
> This should require a minimal change to browsers,
> as the HTML features supported by a browser are
> more or less fixed.

The main problem I see with this solution is that it is HTTP specific.
HTML is an SGML application. I believe it is best that a solution is
targeted more in the SGML realm so authors have more control on how a
document will appear based upon a client's conformance level. Plus not
all HTML documents are served via HTTP.

> On the server side, the GET processing module could
> pipe all HTML documents through a CGI filter that
> selectively downgrades the document to eliminate
> features that the browser doesn't support,
> either replacing them with <PRE> (e.g., tables)
> or a canned message saying that this part of the
> document could not be viewed.

Here's where I think it would be better if authors could state in the
document itself what alternatives should be used based on a clients
capabilities. For example, an author might want a list to be used in
place of a table for clients w/o table support, instead of the table
being converted to a <PRE> construct.

--ewh