Just to say that I strongly agree with Jan's points below. We should
work to use the link relation type properly, and not get dazzled by
the current misuse of the alternate relation.
I have been wondering if there would not be a case for different mime
types if one wanted to place a number of representations at the same
url.
One could for example have the following at the same place:
- an html version of a blog post
- an <entry> representation of that blog post
- a <feed> for the history of changes to that blog post
That would suggest having different media types because one could not
place them at the same location if one only has application/atom
+xml . That does not decide the issue as to whether it is a good idea
to do so.
For the moment I find the application/atom+xml;type=entry application/
atom+xml;type=feed more appealing than the other new media types by
the way.
On the other hand having different mime types for every document
format is also crazy. If someone invents a doc to describe cats, and
someone else a doc to describe mice, are they going to need a new
mime type? And what about a doc to describe policemen, and a doc to
describe people? We could end up quickly with an infinite number of
mime types which clearly would not help interoperability.
Henry
On 6 Dec 2006, at 23:22, Jan Algermissen wrote:
On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote:
It seems pointless for atom:link to have a type attribute at all
then. You should be able to decide anything you need to decide by
GETting the resource (and sometimes parsing it). Why did we add
such a useless feature to the spec?
I am pretty sure it wasn't added for being able to tell people:
"Look, at the other end of this link is a feed".
Seriously: how many feed readers are out there that base the
decision wheter something is subscribeable on the type attribute of
a link rather then on the link type?
As an analogy: HTML browsers look for stylesheets where it says
<link rel="stylesheet" type="text/css" href="/style.css" />
and not
<link rel="alternate" type="text/css" href="/style.css" />
Eh?
Jan
On 6 Dec 2006, at 11:42, Jan Algermissen wrote:
On Wednesday, December 06, 2006, at 08:30PM, "Antone Roundy"
<[EMAIL PROTECTED]> wrote:
On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:
I'd say: stick with the one media type that is currently there -
there is no problem, just misconception about what it means to
subscribe.
A few reasons why a user agent might want to be able to tell the
difference between a link to a feed and a link to an entry beforehand
is in order to:
But that is an issue of linking semantics, not link target media
types. I'd expect the user agent to look for links with 'here is a
feed' semantics instead of looking for (arbitrary) links to certain
media types.
IMHO, there is something going wrong somewhere - and it ain't the
media type.
I completely agree.
On 6 Dec 2006, at 14:26, Jan Algermissen wrote:
To make that decision, the agent has to look at the
representation and
the it is insignificant overhead to see if the thing returnes <feed>
or <entry>.
Not if the resource needn't be GET in the first place. If the
whole operation can be decided upon the Content-Type returned in a
HEAD request, or
Ok, HEAD would save the extra payload, but....I still think the
reason for subscribing is NOT how the representation at the other
end looks, it is based on the link semantics.
