Tim,
On 12/12/06, Tim Bray <[EMAIL PROTECTED]> wrote:
I seems obvious to me that Atom Feed and Entry docs are potentially quite different things which can be used for entirely different purposes. The contention that an Entry doc is somehow really the same as a one-entry Feed doc is entirely unconvincing. The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG finding on Authoritative Metadata (http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear that it's advantageous to use HTTP headers to distinguish between different kinds of representations.
Ok, well, I've already voiced my disagreement that "entirely different purposes" necessitates a new media type using HTML as an example. I also disagree that the TAG finding has any relevance here, except insofar as it says that a media type authoritatively determines meaning by virtue of pointing at a spec ... but every option on the table, including doing nothing, does that. But so be it, I'm happy to move on ...
So I guess I'm in favor of us writing something down to address this problem. RFC4287 is now pretty widely implemented, so there is a distinct cost to screwing around with the well-known application/atom+xml. On the other hand, my perception is that virtually all software that knows about 4287 knows about feeds, rather than entries. Thus, it seems to me that introducing a parameter so that existing software might see application/atom+xml;type=feed *might* break some software.
Maybe, but I'd be surprised. Though not, AFAIK, prescribed behaviour, convention is that unknown extension parameters are ignored. Implementors?
But introducing a new media-type application/atom-entry+xml which only goes with standalone feed documents is very unlikely to break anything.
I think it would break servers. Consider GData apps. Their docs aren't clear (tsk, tsk!) about the use of a media type when inserting entries[1], but if they're doing it properly then their services should be keying off of "application/atom+xml", and so will break if that's changed. Other server implementations should have the same issue, of course.
So I'm for James' option B) application/atom-entry+xml
I'm -1 on that, but +1 on the type parameter. Cheers, [1] http://code.google.com/apis/gdata/protocol.html#Inserting-a-new-entry Mark.
