[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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,
On 12/1/06, Mark Baker <distobj@xxxxxxx> wrote:
Urgh, sorry for my tardiness; I'm falling behind on my reading.
On 11/30/06, Thomas Broyer <t.broyer@xxxxxxxxx> 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=""
Not particularly useful for subscription (or anything else for that
matter) is it? This would be better;
<link rel="feed" type="text/html" href=""
Autodiscovery should ideally be based primarily on link types, and
only secondarily - as an optimization - on media types. Even this
<link rel="feed" href=""