Subject: New Link Relations -- Last Call

From: Mark Nottingham <[email-masked]>
Date: Sat, 22 Oct 2005 10:20:15 -0700

I've replaced "subscribe" with "current"; otherwise, these are the  
same as in the last round. I think they're ready to go -- any more  
comments?

  -  Attribute Value: previous
  -  Description: A URI that refers to the immediately preceding  
document in a series of documents.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Automated agents should take care when  
this relation crosses administrative domains (e.g., the URI has a  
different authority than the current document). Such agents should  
also take care to detect circular references.

  -  Attribute Value: next
  -  Description: A URI that refers to the immediately following  
document in a series of documents.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Automated agents should take care when  
this relation crosses administrative domains (e.g., the URI has a  
different authority than the current document). Such agents should  
also take care to detect circular references.

  -  Attribute Value: first
  -  Description: A URI that refers to the furthest preceding  
document in a series of documents.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Automated agents should take care when  
this relation crosses administrative domains (e.g., the URI has a  
different authority than the current document). Such agents should  
also take care to detect circular references.

  -  Attribute Value: last
  -  Description: A URI that refers to the furthest following  
document in a series of documents.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Automated agents should take care when  
this relation crosses administrative domains (e.g., the URI has a  
different authority than the current document). Such agents should  
also take care to detect circular references.

  -  Attribute Value: current
  -  Description: A URI that, when dereferenced, returns a feed  
document containing the most recent entries in the feed.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Automated agents should take care when  
this relation crosses administrative domains (e.g., the URI has a  
different authority than the current document).

--
Mark Nottingham     http://www.mnot.net/

---

From: Elias Torres <[email-masked]>
Date: Sat, 22 Oct 2005 14:01:57 -0400

What's the difference between current and last?

Elias

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Oct 2005 11:08:17 -0700

+1

Mark Nottingham wrote:

>  -  Description: A URI that refers to the furthest preceding  document 
> in a series of documents.
>  -  Description: A URI that refers to the furthest following  document 
> in a series of documents.

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Oct 2005 11:33:24 -0700

"last" has no time component... it merely reflects the last document in 
a linked list of documents.
"current" indicates the document that contains the most recently updated 
entries...

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 22 Oct 2005 11:29:32 -0700

When you dereference "current", you'll always get a feed document  
that contains the most recent entries in the feed. There's  
effectively a guarantee that the latest entries will be there.

When you dereference "last", you'll get a feed document containing  
the furthest following document in a set of documents. The nature of  
the set and its members is undefined -- it could be the last feed  
document, but it could also be the last entry document, and the set  
could be search results, archives, or anything else. There isn't a  
guarantee it'll always have the latest entries in it.

---

From: Elias Torres <[email-masked]>
Date: Sat, 22 Oct 2005 15:04:45 -0400

cool. +1 then.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 22 Oct 2005 20:39:27 +0200

> What's the difference between current and last?

If I’ve followed the discussion correctly: “current” is live and
something you might subscribe to. “last” may or may not be
static.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: [email-masked] (Peter Robinson)
Date: Sun, 23 Oct 2005 21:04:11 +0100

> same as in the last round. I think they're ready to go -- any more  

I prefer 'subscribe' because it better describes the meaning and
intention behind the link, but I can live with 'current' if that is the
consensus.  I am also worried that this is being pushed through too
quickly.

>   -  Attribute Value: next
>   -  Attribute Value: first
>   -  Attribute Value: last
>   -  Description: [consequent descriptions]

OpenSearch uses 'next' to go from page=1 to page=2.  The natural paging
setup for an inremental feed that is also an OpenSearch results feed is
to have rel=current (aka rel=subscribe) point to the first page of
results (i.e. page=1).

Is it the intention that history reconstruction uses 'next' links to go
back into the past?

If so I think that must be made much more explicit in the descriptions,
since it is not the natural interpretation if you come at this purely
from the standpoint of blog history.

On the other hand, if that is *not* the intention then paging for
history and paging for OpenSearch will be incompatible.

Regards,

Peter
-- 
Peter Robinson
<http://www.ticketswitch.com/> Concerts, sport and theatre tickets

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 23 Oct 2005 14:34:33 -0700

Hi Peter,

On 23/10/2005, at 1:04 PM, Peter Robinson wrote:
> consensus.

Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas  
you say you can live with 'current'. So, at this point it looks like  
'current', unless other people come forward. I flirted with "recent"  
briefly; anybody strongly like that one?

> I am also worried that this is being pushed through too
> quickly.

I appreciate that, but it's a bit of a chicken-and-egg problem; we  
won't get all of the implementation experience until it's defined and  
widely deployed. Most of the problems that people have postulated  
with these extensions have to do with conflicts with future  
extensions, which by their nature are hard to accommodate. Or, they  
are matters of style or just judgement calls; we'll never make  
everybody happy on those issues, and waiting won't help.

> history and paging for OpenSearch will be incompatible.

Right now, the plan forward seems to be that 'next' et al will be  
purposefully generic; i.e., they won't mean much until used in  
conjunction with another extension (in my case, fh:incremental).

My plan for feed history is to recommend people walk both 'previous'  
and 'next' from the subscription feed, so that it doesn't matter  
which "way" the feed goes.

Cheers,

---

From: "James Holderness" <[email-masked]>
Date: Mon, 24 Oct 2005 00:56:03 +0100

> same as in the last round. I think they're ready to go -- any more  

+1 on everything

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 24 Oct 2005 05:27:44 +0200

* Mark Nottingham <[email-masked]> [2005-10-23 23:40]:
> Well, Tim seemed to have a pretty strong -1 on 'subscribe',
> whereas you say you can live with 'current'. So, at this point
> it looks like 'current', unless other people come forward. I
> flirted with "recent" briefly; anybody strongly like that one?

I like “recent” better than “current,” and I agree with Tim on
“subscribe.” But neither of the alternatives seems like a great
fit.

I thought about it for a while and came up with “live.” It would
seem to me that it describes the link target with a qualtatively
stronger assertion than either “current” or “recent,” and that it
is more likely to intuitively convey what it’s supposed to mean,
ie “if you want to subscribe to something, this link is the best
candidate.”

But ultimately I’m okay with any of the non-“subscribe”
propositions.

Regards,

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 24 Oct 2005 10:37:50 +0200

> briefly; anybody strongly like that one?

Maybe it is clear to everyone but me...however i do not see the damage 
done by using rel="self" instead of inventing a new relation. Could 
someone bother to explain that?

I know the definition in the format spec says it points to an 
"equivalent resource", but it also says that "This is the preferred URI 
for retrieving Atom Feed Documents representing this Atom feed." I 
probably do miss something important here, but
a) "equivalent resource" says either nothing or lets you enter a mine 
field while roy t. machine guns you
b) "representing this Atom feed" requires some king of dualistic 
thinking: the whole Atom feed is composed of several Atom feed 
documents which are linked with "prev" and (maybe) "next" relations. 
"self" points to the URI for the overall feed and has the same value in 
all chained feed documents (or feed chunks as i would call them)

Can I convince anyone to enter the land where an Atom feed is composed 
of one or more Atom feed documents?

Cheers, Stefan

---

From: Henry Story <[email-masked]>
Date: Mon, 24 Oct 2005 11:53:24 +0200

I agree "self" would do well. But it is true that it's current  
definition
is a little vague. I don't suppose one can refine it in a way  
consistent with its current definition?

In any case this all looks good to me. As soon as we agree on the  
names, I will
implement these links in BlogEd, so that the web server can keep a  
complete history of
published changes. What would I need to add to my feed to make it  
clear that I my
feed is incremental (I think that's what my feed would be)?

Henry

On 24 Oct 2005, at 10:37, Stefan Eissing wrote:
>> whereas you say you can live with 'current'. So, at this point it  
>> looks like 'current', unless other people come forward. I flirted  
>> with "recent" briefly; anybody strongly like that one?
>>
>
> Maybe it is clear to everyone but me...however i do not see the  
> damage done by using rel="self" instead of inventing a new  
> relation. Could someone bother to explain that?
>
> "equivalent resource", but it also says that "This is the preferred  
> URI for retrieving Atom Feed Documents representing this Atom  
> feed." I probably do miss something important here, but
> a) "equivalent resource" says either nothing or lets you enter a  
> mine field while roy t. machine guns you
> documents which are linked with "prev" and (maybe) "next"  
> relations. "self" points to the URI for the overall feed and has  
> the same value in all chained feed documents (or feed chunks as i  
> would call them)
>
> Can I convince anyone to enter the land where an Atom feed is  
> composed of one or more Atom feed documents?
>
> Cheers, Stefan
>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 24 Oct 2005 12:45:21 +0200

* Henry Story <[email-masked]> [2005-10-24 12:00]:
> What would I need to add to my feed to make it clear that I my

By my understanding, incremental is the default semantic for a
feed, so to make it clear that that’s what yours is you would add
nothing.

Regards,

---

From: [email-masked] (Peter Robinson)
Date: Mon, 24 Oct 2005 22:12:34 +0100

Hi Mark,

Mark Nottingham <[email-masked]> wrote:

> > intention behind the link, but I can live with 'current' if that is
> > the consensus.
> 
> you say you can live with 'current'.

I can.

The argument as I understand it is that relations should be nouns rather
than verbs (describing what the link points to rather than what you
should do with it).  I can't argue that point, but I do feel that
'current' less encapsulates the intent than 'subscribe'.  Someone else
suggested 'subscription'.  

This should be my last word on the subject:

Apparently it came as a surpise to some that rel='self' as defined is
not the same as 'the url you should subscribe to' in the general case.
I don't want to make the same mistake yet again.

First example:  consider a statically archived non-incremental
OpenSearch-style feed split into pages:
 <http://www.example.com/feed/2001/page3>
A reasonable interpretation (the only possible interpretation?) of
rel='current' would be this:
 <http://www.example.com/feed/current/page3>
which is certainly not the url you should subscribe to.

Second example:  a dynamic feed where cgi variables are used to set
options, perhaps for use in building an html page of links rather than
normal subscription, but you can come up with other uses:
 <http://www.example.com/feed?year=2001&no_atomcontent=yes>

Rel='current' would point to
 <http://www.example.com/feed?no_atomcontent=yes>
but it would be much better for PubSub or a desktop aggregator to go to
 <http://www.example.com/feed>
if it ever got hold of such a feed.

The second example is (essentially) something I already do.  I don't
expect urls like that to 'escape' into the wild, but I can't prevent it
and I'd like to be able to give an aggregator something meaningful to do
when it does happen.

If we want to define a link relation meaning 'the url you should
subscribe to' then that is what we should define.

> So, at this point it looks like 'current', unless other people come
> forward. I flirted with "recent" briefly; anybody strongly like that one?

I don't think that is any better.

> > I am also worried that this is being pushed through too quickly.
> 
> widely deployed.

That is true, but have you communicated with the OpenSearch people about
this?  I do strongly believe that *here* is the place for work like
this, rather than behind closed doors at Amazon.  But if I was them I'd
feel pretty miffed that this WG appears to have basically stolen their
idea in a desperate 'land grab', and turned it on its head so that it is
(arguably) the complete opposite of their intended definition.

[snips]

> > OpenSearch uses 'next' to go from page=1 to page=2.  The natural
> > paging setup for an inremental feed that is also an OpenSearch results
> > feed is to have rel=current (aka rel=subscribe) point to the first page
> > of results (i.e. page=1).
> >

[...]

> which "way" the feed goes.

I see!  That little nugget of an idea makes me feel a lot more
comfortable about prev/next.  So something that understands
rel=previous, next et al will be able to reconstruct a complete logical
feed, and the history extension will tell it 'which way is up' and
whether it's a traditional 'incremental' feed.  That makes a lot of
sense.

Regards,

Peter