I'm still listening to the debate, but Mark's argument resonates with me. It seems like 'content-type' is more about the expected syntax of the resource at the other end of the wire, not it's semantic meaning. I don't see Atom feeds and entries as syntactically different enough to warrant unique media types, there's lots of existing parsers that seem able to navigate this split just fine already.
I expect that if you associated a 'rel' value with links that point to "application/atom+xml", whether it is expected to be a feed or an entry would probably be part of the 'rel' description and thus not ambiguous at all. I think the discussion started because of the aforementioned issues with the HTML5 link semantics, which is what should probably be fixed. On top of that, the procedural and back compat issues associated with splitting the mime type now just don't seem to make it a win to me. Crazy busy and largely silent, but not completely awol, -- Kyle On 12/1/06, Mark Baker <[EMAIL PROTECTED]> wrote:
Urgh, sorry for my tardiness; I'm falling behind on my reading. On 11/30/06, Thomas Broyer <[EMAIL PROTECTED]> wrote: > I'd prefer basing autodiscovery on the media types and not at all on > the relationships. All a media type tells you (non-authoritatively too) is the spec you need to interpret the document at the other end of the link. That has very little to do with the reasons that you might want to follow the link, subscribe to it, etc.. Which is why you need a mechanism independent from the media type. Like link types. Consider hAtom. If you went by media types alone, you'd be confronted with; <link type="text/html" href="hatom.html" /> Not particularly useful for subscription (or anything else for that matter) is it? This would be better; <link rel="feed" type="text/html" href="hatom.html" /> Autodiscovery should ideally be based primarily on link types, and only secondarily - as an optimization - on media types. Even this should work; <link rel="feed" href="hatom.html" /> Mark.
