RE: content negotiation anti-principle

> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf Of
> Elliotte Rusty Harold
> Sent: Sunday, January 05, 2003 5:05 PM
> To: www-tag@w3.org
> Subject: Re: content negotiation anti-principle
>
>
>
> At 8:09 AM +0900 1/2/03, Gavin Thomas Nicol wrote:
> >Perhaps the real problem is that there's no easy way to force a
> particular
> >representation to be returned? Content negotiation is at a lower
> level than
> >remembered URL's, so there's some "gap" between the implied
> semantics and the
> >actual protocol.
>
> There are definitely times when I've wanted to point to a version of
> a resource in a particular language, or point to several translations
> in different languages, and not allow auto-content negotiation to
> happen. I've noticed that sites which use content-negotiation get in
> my way and make this difficult. Sites  that don't use content
> negotiation make this easy.

So what's the alternative? Let's keep things simple and discuss language
selection based on the Accept-Language header.

a) Use content negotiation, and supply whenever possible a content location
header that gives you the URL of a language-specific resource (this is what
Apache does)

b) Server uses Accept-Language header to redirect (HTTP 301/302) to a more
specific URL (is this legal?). Disadvantage: extra roundtrip.

c) Client-side scripting.

d) ...?

I think a) works very well. In many cases, I *don't* want to bookmark a
specific version -- maybe I want to forward the URI to somebody who has
different language preferences. However it may be nice that browsers -- when
content-location information is available -- allows the user to select what
to bookmark.

> Again the whole issue of what is a resource rears its ugly head. Is
> it the abstract Platonic document which can be rendered into multiple
> languages? Or is it a particular, concrete representation of that
> document in one language? It really depends on what your local
> process is doing, doesn't it? Sometimes you want one. Sometimes you
> want the other.

Yes. I think in general only the client decice *what* it wants to bookmark,
so it may be good to allow to bookmark both (the request-URI and the
content-location-URI). Maybe we can get this into Mozilla quickly?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Sunday, 5 January 2003 14:19:21 UTC