First and Last are (or at least can be) "static"; i.e. one can read
the relations, as currently written, as saying that they point to the
specific set of entries ("archive") that are first and list,
respectively, at the time that the feed is minted. Subscribing to one
of those would be... bad.
If we had more specific relations, this would certainly be a lot
easier. Keeping everything so loose and semantic-free seems to me
like premature optimisation and a barrier to interoperability.
HTTP, for example, seems to work just fine, despite having concrete
semantics that are grounded in specific use cases for almost all of
its headers (indeed, the least-used ones are those that are more
descriptive).
On 22/10/2005, at 2:10 AM, James Holderness wrote:
Tim Bray 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.
At the time "subscribe" was proposed it wasn't clear that there
would be a "first" and "last". However, since that is now the case,
would it not short-circuit a whole lot of argument if we just threw
out "subscribe" altogether?
Determining whether an Atom document is an archive can be achieved
by looking for the presence of a "prev" link and/or a "first" link
that is not equal to "self". As for finding the subscribtion URI
itself - that should just be the "first" link shouldn't it?
I don't want to get dragged back into a long argument on this so if
you think this is a stupid idea don't expect any defence from me.
I'm just throwing it out there with the hope that it might be
workable.
Regards
James
--
Mark Nottingham http://www.mnot.net/
