Supporting data or ideas: Some interesting links, semantically
speaking, don't even have a fixed MIME type (or not just one,
anyhow). If we wanted to add link relations for photo shares on
WebDAV repositories, or personal calendars on CalDAV repositories,
you'd want to point to the URL to the appropriate WebDAV collection,
which could return results in HTML (response to GET without any
special stuff), XML (response to PROPFIND), or iCalendar (in the
CalDAV case). Not sure how to fully convey all of that, but at least
not overloading MIME type with semantic meaning helps the situation.
Lisa
On Dec 1, 2006, at 9:17 AM, Kyle Marvin wrote:
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.
