On 12/1/06, James M Snell <[EMAIL PROTECTED]> wrote:
Kyle Marvin wrote:
> [snip]
> 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.
>
Not necessarily.
Consider:
<link rel="alternate" type="application/atom+xml" href="feed.xml" />
<link rel="alternate" type="application/atom+xml" href="archive.xml" />
<link rel="alternate" type="application/atom+xml" href="entry.xml" />
What is the purpose of using alternate links? What is a UA supposed to
do with 'em? Why did I as a content publisher choose to use the
"alternate" link relation? Are all of these links of equal value to all
UA's? Are they all expected to be processed in the same basic way?
Should an "archive" feed be treated the same way as a "subscription" feed?
This points out that the above rel+type don't carry sufficient semantic
meaning to help a UA decide what to do with them. I don't think anyone on
this thread is disagreeing with that. This discussion (as I understand it)
is about what to do given that ambiguity. You can either get more specific
with the rel value, with the content-type, or with both.
Consider this use case:
In IBM's Activities implementation, each of our "Activity" collections
are entries in a top level master collection. Every "Activity" has
several representations: An Atom entry, An Atom feed, A RSS feed, A HTML
page, etc. On the html page I want to be able to link to each of the
various representations as alternates. I also want folks to be able to
subscribe to the Atom feed and allow the folks who are building
APP-enabled editing tools to autodiscover the edit uri of the entry. I
don't want UIs to show a subscription link to the Atom entry
representation.
What I want is something like this:
<link rel="alternate subscribe"
type="application/atom+xml"
href="feed.xml" />
<link rel="alternate edit"
type="application/atom.entry+xml"
href="entry.xml" />
<link rel="alternate subsribe"
type="application/rss+xml"
href="rss.xml" />
Given these links I have all of the information I need:
* There are three alternate representations: An Atom Entry, An Atom
Feed and an RSS Feed.
* There are two links I can subscribe to: An Atom Feed and an RSS Feed
* There is one edit link
Note that this clearly separates the purpose of the link (rel) from the
resource type. I don't care what the value of the type attribute is, if
rel includes the keyword "subscribe" (or "feed", doesn't matter) then I
know I can subscribe to that resource. If the rel contains the keyword
"alternate" I know it's an alternate representation, no other semantics
are implied. Each of the keywords in the rel attribute are completely
orthogonal to one another.
So you've solved the above problem by changing both the rel value and the
content-type (in a few cases). I'd propose that changing the rel value
(alone) would a sufficient solution. The above "rel" values provide
sufficient information with some implied expectations about feed vs. entry
resource and potential usage of the href. The implied nature could be
explicit if these rel values were enumerated somewhere (for example, you
subscribe to feeds, and you edit entries).
Note also that there is a clear separation between the Atom Feed and
Entry types. These are different document types intended for different
audiences and deserve different media types.
I see the separation but I'm still missing a clear justifiication for it. I
don't see content-type as having anything to do with the "audience". It's
about what media format you'd get back if you dereference the href and rel
is about how you can interpret/interact with it. I feel like the primary
audience for content-type is likely to be used in selecting some type of
parser when retrieving the resource. Orthogonal to this, the "rel" value
assigns some semantic meaning to the resource (what does the entry or feed
describe) and might also specify what interaction model you might expect via
the href (ex. "edit" implies APP edit semantics on an entry resource).
Cheers!
