I feel like this whole discussion about whether an entry is logically equivalent to a feed is a little bit of a red herring. To me, the important justification for forking the Atom content type comes from a belief that this is useful information that you need *before* you retrieve/process the target document.
I think we can all agree that parsing/syntax alone isn't enough to justify this; there are many existing Atom parsing impls that can handle the current approach just fine, and lots of counter examples of other MIME types that do even more overloading of multiple semantic content types under a single syntactic content type (ex "text/xml"). Something which can't handle the current range of potential Atom document contents for "application/atom+xml" doesn't seem like a strong argument either. We all know it's _possible_, it's just that in some contexts (like feed reading) it hasn't been considered _interesting_ to implement entry handling. I don't think a new MIME type fixes this, there are lots of real world cases of software developers who only implement a subset of a spec that they find is interesting or useful, it's always gonna happen but often gets fixed. I'm still looking for one or two use cases where having the distinction between whether a referenced document points to a feed or an entry is a vital thing. I can honestly say from the GData side we haven't seen this need yet, but that doesn't mean it exists. A link relation mght imply the content type (ex 'subscribe') or might be a logical relation that can apply to multiple content-types (as Lisa noted), but in the latter case what benefits do feed vs. entry doc distinction buy you? -- Kyle On 12/6/06, Andreas Sewe <[EMAIL PROTECTED]> wrote:
James M Snell wrote: > Actually, for the form "application/atom+xml;type=entry" it's more > likely that browsers will completely ignore the type param as they do > currently. Well, if a browser ignores a media type's parameters, it will have to face the consequences: In the case of "application/atom+xml;type=entry" it would get "application/atom+xml" which means 'either an Atom Feed or Entry Document'; if it cannot handle Atom Entry Documents without breaking, it does not properly implement RFC 4287. But your point that *current* browsers silent discard a "type" parameter on "application/atom+xml" is moot anyway since the *current* Atom RFC specifies no such parameter. That being said, an *optional* type parameter offers the cleanest solution to distinguishing between the following three cases: 1) Either an Atom Feed or Entry Document 2) An Atom Feed Document 3) An Atom Entry Document If RFC 4287 had defined separate media types for the latter two cases, we wouldn't have this problem, of course: "Accept: application/atomfeed+xml, application/atomentry+xml" would cover the first case just fine. But since the RFC sadly doesn't I am extremely reluctant to either deprecating the use of "application/atom+xml" for Atom Entry Documents or to introducing three media types overall when an optional parameter suffices. So, James, what is wrong with "application/atom+xml;type=[entry|feed]"? (A slim majority on this list seems to prefer it over defining separate media types.) Regards, Andreas Sewe
