Re: The type attribute and HTTP content negotiation.

[Eric Scheid <eric.scheid@xxxxxxxxxxxxxxx>]

On 30/12/03 9:19 PM, "Danny Ayers" <danny666@xxxxxxxxxxx> wrote:

> Putting both types of content inline in a single feed sounds a bit clunky.
> Autodiscovery needs to be richer? e.g.
> 
> <link rel="alternate text/html" type="application/atom+xml"
> href="http://example.com/atom.xml"; />
> 
> <link rel="alternate application/xhtml+xml" type="application/atom+xml"
> href="http://example.com/atom.xml"; />

I'm not real clear on what you are saying here? Is the thing at the other
end of the href text/html or application/xhtml+xml ... or
application/atom+xml?

>> The new format requires the type attribute, which
>> lists the target document's media type, like this:
>> 
>> <link rel="alternate" type="text/html"
>> href="http://www.example.com/"/>
>> 
>> As regular readers know, we're serving our documents
>> as 'application/xhtml+xml' to browsers that support it
>> and 'text/html' to those that don't.

This looks like it has more purity...

<link rel="alternate" type="text/html" href="http://www.example.com/"; />
<link rel="alternate" type="application/xhtml+xml"
href="http://www.example.com/"; />

That is: the same href in both, the same @rel, but different @types.

In a perfect world the type attribute would be passed to whatever is being
asked to retrieve the resource, and it would specify that type in it's http
request as to what type of resource it wants back (ie. content negotiation).

As to which <link> is selected ... that's the same problem if they were
different @hrefs with application/pdf and image/jpeg ... except having the
same @href for different types is a hint that content negotiation could
occur.

e.