Content types are only useful when they help to differentiate how a document is to processed. If it was all about the format we could have just used application/xml all along. IMHO, There is already sufficient evidence that entry documents and feed documents are processed differently and thus deserve different content types.
- James Henry Story wrote: > > 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. > >
