Re: Hyperlinks and content negotiation

Thomas Broyer wrote:
> First, let me reiterate an argument from last year's discussion: are
> you proposing also adding accept-language, accept-encoding and other
> accept-* attributes? If not, then you're only solving a very small
> part of the problem (provided there's a problem to be solved).
>   

http://lists.w3.org/Archives/Public/public-html/2009Oct/0594.html

"On multiple human languages - there is Accept-Language header in HTTP
for this purpose. That is an equally valid form of content negotiation;
however it's practical use is more limited because translations are
barely ever controlled mechanically by the server (i.e. one translation
is not automatically generated from another). This is a situation in
which it *does* make sense to identify them as separate resources, I'm
happy to explore why this is the case in more detail if it is not
immediately clear. If you felt that an equally strong case could be made
for language (or even encoding) as for content-type then perhaps an
additional attribute for that could also be considered?"

In terms of application flow, in practice, not all content-negotiation 
controls are created equal - I think content-type negotiation is by far 
the most relevant and does actually solve a large part of the problem.

If the costs of also adding attributes for language were relatively 
small, I would certainly not be against this however.


> Also, why couldn't UAs tweak their Accept-* headers depending on
> type="" and hreflang="" attribute values?
>   

I pointed to this in the original post. The only potential down-side to 
this would be confusing the established significance of those existing 
attributes.

As long as the mechanism is explicit in the spec, it really matter what 
attributes are used.

> The problem is that you want to leverage HTTP's ability to
> transparently provide variants for a same resource, and at the same
> time you want to be able to link to a specific variant. If you link to
> something, isn't it a resource on its own? (i.e. with its own URI)
>   

No, I don't Accept :) that as sufficient reasoning. Do you have evidence 
and/or relevant specifications to this effect?

> You're now bringing cache invalidation as an argument, but that's
> already solved by RFC 2295 and RFC 2296.
>   

Cache invalidation was always an argument since the objective all along 
has been to increase the visibility of HTTP messages in HTML driven 
applications.

Increased visibility allows for more efficient layering via 
intermediaries; and caching mechanisms are a common and important 
example of this.

> On Mon, Oct 19, 2009 at 1:51 PM, Mike Kelly <mike@mykanjo.co.uk> wrote:
>   
>>>> Without a formal mechanism in HTML which can specify to UAs the
>>>> contextual content-type preference for a given hyperlink, HTML is not
>>>> a viable hypermedia format for systems which must rigorously leverage
>>>> HTTP conneg
>>>>         
>>> What systems "must rigorously leverage HTTP connect" (and what
>>> does that mean?)
>>>       
>> I was trying to describe implementations which rely exclusively on conneg
>> for negotiating representations of resources and deliberately avoid using
>> multiple URIs for this purpose.
>>
>> JSR 311 (JAX-RS) is an example technology with this constraint
>>
>> https://jsr311.dev.java.net/nonav/releases/1.1/spec/spec3.html#x3-320003.5
>>     
>
> I'm far from being a JAX-RS expert but AFAICT, JAX-RS doesn't rule out
> those three cases

The examples you provided are defined as "Sub *Resources*":

https://jsr311.dev.java.net/nonav/releases/1.1/spec/spec3.html#x3-310003.4.1

- Mike

Received on Monday, 19 October 2009 15:07:08 UTC