On Oct 22, 2005, at 3:28 AM, Eric Scheid wrote:
I think you've got the special case turned around. That is, if you are
looking at a representation of the active feed then the 'self' link
would
happen to match the 'subscribe' link, which is the exception. The
defining
text in the spec says this about 'self'
The value "self" signifies that the IRI in the value of
the href attribute identifies a resource equivalent to
the containing element.
atom:[EMAIL PROTECTED]'self'] can also appear in atom:entry, which would
be used
for pointing to Atom Entry Documents, which explains why the text
says "the
containing element". I don't believe anyone is thinking we should
be able to
subscribe to Atom Entry Documents.
I'm entirely unconvinced. There are two kinds of feed, the dynamic
kind and the static kind. For dynamic feeds, use rel="self" to
subscribe. For static feeds, use some new relationship like
rel="dynamic" to point to the dynamic version that you might
subscribe to.
I agree that, in retrospect, the spec should have said that one
intended use of rel="self" is to support auto-subscribe. I don't
think adding on a new link relationship is the right answer.
Are we yet in a situation were we have a preponderance of deployed
feeds
using 'self' to mean 'subscribe'? Actually, that's the wrong
question to ask
(see below)
Well, all the Atom feeds I see use rel="self" in the way you'd expect.
Are we yet in a situation were we have preponderance of deployed
applications that look for 'self' for subscription purposes?
Well, no, because we actually don't have that many apps yet that
really grok Atom. When they do, and they want to do auto-
subscription, Atom is well-equipped to support it.
I think we're in the early days of Atom 1.0 adoption, and we can
very likely
talk up via blogs, articles, etc the idea of "subscribe in the
general case"
using @rel='subscribe'.
No. We already have a way to do that and don't need to invent another.
-1 on rel="subscribe". -Tim
(oh, and I should have said, +1 on the rest of those relationships)