On 22/10/05 4:25 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> On consideration, I am -1 to rel="subscribe". The reason is this:
> one of the big potential value-adds Atom brings is a standards-
> compliant way to do one-click auto-subscribe, via <link rel="self"/>
> You are proposing to introduce a <link rel="subscribe" /> which
> is there to support autosubscribe. But, it turns out, only in the
> special case where the feed is static and you wouldn't actually
> subscribe to it. I think the risk of confusing implementors and
> weakening the value proposition around <link rel="self" greatly
> exceeds the benefit of supporting this special case.
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.
> Plus, I think the thing isn't properly named. It isn't actually
> "subscribe in the general case",
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)
Are we yet in a situation were we have preponderance of deployed
applications that look for 'self' for subscription purposes?
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'.
The only deployed inertia we have to over come is with aggregator
developers. We don't have to worry about any deployed feeds that only have
'self' links (I'll explain in a moment). We only need to explain things to
the various aggregator developers. The general idea would be for the
application to look for a 'subscribe' link first up, and failing that a
'self' link. Very simple.
We don't have to worry about deployed feeds with 'self' links. They won't
have 'subscribe' links unless they put effort into putting them there, in
which case they could quite simply s/self/subscribe/. If a feed does not
have 'subscribe' then 'self' would be found with the fall back.
Could there eventually be feeds out there with only 'subscribe' and not
'self' ... they would be funky but not invalid (it's a SHOULD requirement,
not a MUST) ... and the only applications that would fail to subscribe would
be outdated p.o.c.
> it's "in the special case where the
> version you are looking at is static, point to the places where the
> changes happen because they don't happen here". So, perhaps we
> should consider rel="current-self" or rel="dynamic-version" or some
> such.
I'm thinking is that 'self' was not properly named in the first place. If
the intent of that link was for subscription purposes, for pointing to the
most recent updates for that feed, then it should have been named
'subscribe' or (as you say) a descriptive word indicating that is the sort
of thing one would want to do with it.
The idea of embedding a link to the URI to subscribe to was a very good one.
Calling it 'self' was a bone-headed one. We were so caught up with the idea
of being able to subscribe to the active feed we forgot to consider the case
of seeing that link in the context of an archive.
This is the same class of bone-headed mistake as using
/html/head/[EMAIL PROTECTED]'alternate',@type="application/atom+xml"] for feed
auto
discovery. Consider for example this HTML page...
<html>
<head>
<title>Archive for January 2005</title>
<link type="application/atom+xml" rel="alternate" href="[1]">
<link type="application/atom+xml" rel="alternate" href="[2]">
</head>
<body>...</body>
</html>
Now, one of those two links points to the URI you should subscribe to if you
want to see the most recent updates, and the other link points to a URI
which will give you the Atom Feed Document for the Archive for January 2005.
Only problem is, you can't tell them apart.
We painted ourselves into a corner.
This 'self' thing is the same class of error as 'alternate'.
Can we please learn from that mistake?
> Finally, markup design that claims to enforce a specific action is
> always questionable. The great virtue of descriptive markup in
> general is that the tags tell you not what to do with things but what
> they are. So on that basis, rel="current-version" or something is
> better design.
The verb/noun thing is a good point ... but how could 'self', which
generally speaking, would point to a completely different set of data, be
considered "descriptive"?
FWIW, @rel="subscription" was offered up first, but then got switched to
'subscribe'.
e.
