Subject: Re: Feed History -04

From: [email-masked] (Peter Robinson)
Date: Sun, 2 Oct 2005 11:32:25 +0100

James Holderness <[email-masked]> wrote:

[About feed history and atom:link vs. fh:prev]

> I'm surprised nobody else has commented though. To me this seems like one of
> the most important extensions to Atom/RSS, and yet there aren't exactly
> hordes of people rushing to implement it or at least committing to do
> something once it's officially released. Or have I just missed previous
> discussions on the subject?

As a feed producer, I would love for feed consumers to be able to pull
back the history of my feeds if they choose.  But unfortunately seeing
the way this discussion is going, and the (for me) closely related
ordering extension, I'm not convinced I will be able to use them.

Of couse if you don't turn up, you don't get to complain about decisions
that get made, and unfortunately I don't have as much time as I'd like
to participate in these discusions.  But it's not that I don't care.

As far as the question at hand, I would be able to implent it in my
Atom/RSS2 feed generator easily enough either way.  Obviously it will be
a small amount of extra work if there is a format-dependent difference.
Playing devil's advocate for a minute, is it very wrong to use atom:link
for feed history in *RSS2*?

Regards,

Peter
-- 
Peter Robinson
<http://www.ticketswitch.com/>

---

From: James M Snell <[email-masked]>
Date: Sun, 02 Oct 2005 09:27:22 -0700

>for feed history in *RSS2*?
No, it is not wrong to use atom:link in RSS2.  There is existing 
precedence for this and it really does make a whole lot of sense.

- James

---

From: Luke Arno <[email-masked]>
Date: Sun, 2 Oct 2005 18:15:34 -0400

> precedence for this and it really does make a whole lot of sense.

yup.

http://opensearch.a9.com/spec/opensearchresponse/1.1/

for instance.

- Luke

---

From: "James Holderness" <[email-masked]>
Date: Mon, 3 Oct 2005 00:47:20 +0100

> http://opensearch.a9.com/spec/opensearchresponse/1.1/

Also used in the Universal Subscription Mechanism:

http://www.kbcafe.com/rss/usm.html

---

From: Ian Davis <[email-masked]>
Date: Mon, 03 Oct 2005 08:02:07 +0100

On 01/10/2005 01:05, James Holderness wrote:
> 
> Mark Nottingham wrote:
>> Thanks for the feedback. As I've explained before, I have a pretty  
>> strong preference for the current design, to make it usable in other  
>> formats; i.e., the scope of this is not just Atom (which is why I'm  
>> probably going to do it as an Individual submission).
> 
> At first I thought this was a good idea, but I'm starting to have second 
> thoughts. The spec as it stands is fine for RSS 2, but I can see a lot 
> of Atom people thinking that you should be using atom:link (as Henry 
> suggested) and not wanting to "corrupt" their nice new format. No doubt 
> the RSS 1 folks have their own preference for where this should be going 
> and will probably be even more adamant that you do things the correct 
> way (not sure what that might be - something using dc:relation maybe?) I 
> would worry that if they don't like it, they won't use it.

I think the RSS 1.0 folks would be happiest with a self-contained 
extension in its own namespace with each term having clear unambiguous 
semantics. I think Mark's design achieves this.

Ian
-- 
http://internetalchemy.org | http://purl.org/NET/iand
Working on... Silkworm <http://silkworm.talis.com/>

---

From: "James Holderness" <[email-masked]>
Date: Sun, 9 Oct 2005 09:39:18 +0100

Following up on the idea of using atom:link instead of fh:prev, I recently 
came across an old article by Mark Pilgrim on XML.com 
(http://www.xml.com/pub/a/2004/06/16/dive.html) in which he discusses the 
atom:link element and the various rel attributes it supports. He 
specifically brings up the issue of feed history and using next and prev to 
link archives together.

It sounded to me as if he was talking about an existing feature in the 
spec - it wasn't like he was proposing it as a new idea. So was this 
something that used to be part of an old version of the spec that was later 
removed? Or was this an early proposal that was never accepted into the 
spec?

Also of interest: there's a link from that article to his archives on 
diveintomark.org which actually include next and prev links in the feed. I'm 
almost inclined to add support for that just so I can access those old 
posts. There used to be some excellent articles on his site.

---

From: Henry Story <[email-masked]>
Date: Sun, 9 Oct 2005 10:47:17 +0200

I believe it was part of atom 0.3, and for some complex reason I never
bothered trying to understand someone decided it should be moved over to
the protocol side of things. Probably just because the debate was  
taking up
too much time...

So yes. 'prev' and 'next' have always been intended to be there in  
the link element...

Henry

On 9 Oct 2005, at 10:39, James Holderness wrote:
>
> Following up on the idea of using atom:link instead of fh:prev, I  
> recently came across an old article by Mark Pilgrim on XML.com  
> (http://www.xml.com/pub/a/2004/06/16/dive.html) in which he  
> discusses the atom:link element and the various rel attributes it  
> supports. He specifically brings up the issue of feed history and  
> using next and prev to link archives together.
>
> It sounded to me as if he was talking about an existing feature in  
> the spec - it wasn't like he was proposing it as a new idea. So was  
> this something that used to be part of an old version of the spec  
> that was later removed? Or was this an early proposal that was  
> never accepted into the spec?
>
> Also of interest: there's a link from that article to his archives  
> on diveintomark.org which actually include next and prev links in  
> the feed. I'm almost inclined to add support for that just so I can  
> access those old posts. There used to be some excellent articles on  
> his site.
>

---

From: Henry Story <[email-masked]>
Date: Sun, 9 Oct 2005 11:16:24 +0200

It occurred to me that I should think a little more before speaking.

There seems to be a history of the atom spec here:

http://bitworking.org/projects/atom/

I could not find the prev link in any of the specs. So I guess I was  
mistaken.
But I also always thought of prev and next as being very good  
candidates for
the link element.  I never raised my voice against the move at the  
time because
I assumed most decisions on this list were good ones.

There is one reference to prev and next here:
     http://www.intertwingly.net/wiki/pie/LinkTagMeaning

Henry

On 9 Oct 2005, at 10:47, Henry Story wrote:
>> the spec - it wasn't like he was proposing it as a new idea. So  
>> was this something that used to be part of an old version of the  
>> spec that was later removed? Or was this an early proposal that  
>> was never accepted into the spec?
>>
>> the feed. I'm almost inclined to add support for that just so I  
>> can access those old posts. There used to be some excellent  
>> articles on his site.
>>
>

---

From: "James Holderness" <[email-masked]>
Date: Sun, 9 Oct 2005 14:25:31 +0100

Funny you should say that. When you told me it was part of Atom 0.3 I also 
thought to myself that I should have checked that before posting. 
Technically you were correct. Version 0.3 of the syndication format doesn't 
mention next and prev explicitly, but it does say (in section 3.4.1) that 
the rel attribute "must be one of the values enumerated in the API 
specification". And at the time the API specification included (amongst 
others) start, next and prev. They were only recently removed (in 
draft-ietf-atompub-protocol-03). If you look at the draft prior to that 
you'll find them in section 3.5.1.

Regards
James

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 9 Oct 2005 09:42:47 -0700

"Managing Feed State" was a placeholder I put in the original Atom  
spec draft <http://www.mnot.net/drafts/draft-nottingham-atom- 
format-00.html#rfc.section.4> for just this kind of discussion. The  
WG couldn't come to a consensus on a mechanism (my proposal was  
<http://www.intertwingly.net/wiki/pie/PaceFeedState>), so we removed  
that section (earlier this year, IIRC).

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

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

---

From: Joe Gregorio <[email-masked]>
Date: Sun, 9 Oct 2005 15:02:32 -0400

> I could not find the prev link in any of the specs. So I guess I was

It's in there:

  http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.5.4.1

So -1 to draft-nottingham-atompub-feed-history-04.txt for not using
a link tag of rel="prev".

   -joe

--
Joe Gregorio        http://bitworking.org

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 9 Oct 2005 12:46:46 -0700

The format doesn't reference the API document any more, and the  
current API document <http://www.ietf.org/internet-drafts/draft-ietf- 
atompub-protocol-04.txt> doesn't include anything about that link  
relation; it was removed.

________________________________________________________________________________
BEAWorld 2005: coming to a city near you.  Everything you need for SOA and enterprise infrastructure success.

Register now at http://www.bea.com/4beaworld

London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec

---

From: Robert Sayre <[email-masked]>
Date: Sun, 9 Oct 2005 16:03:53 -0400

On 10/9/05, Mark Nottingham <[email-masked]> wrote:
>
> The format doesn't reference the API document any more,

That's good.

> and the

No, but Amazon OpenSearch has been threatening to register it, FWIW. :)

Robert Sayre

---

From: "James Holderness" <[email-masked]>
Date: Sun, 9 Oct 2005 23:41:35 +0100

In case anyone is interested, the OpenSearch Response draft can be found 
here:

The rel values they support include next, previous (not prev), start and 
end. They have a note next to each saying "This value is pending IETF 
registration". Does that mean they've actually started some kind of 
registration process or they're just hoping to do so at some point in the 
future?

Another issue worth noting is that their example RSS feed is also using 
atom:link to provide this functionality.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 9 Oct 2005 17:45:10 -0700

Looks like the whole "use URIs for non-registered values" approach  
has already gone by the wayside. Oh, well.

Next time, it should just be URIs, period -- no shortcuts.

On 09/10/2005, at 3:41 PM, James Holderness wrote:

> They have a note next to each saying "This value is pending IETF  
> registration process or they're just hoping to do so at some point  
> in the future?

---

From: James M Snell <[email-masked]>
Date: Sun, 09 Oct 2005 21:06:25 -0700

I've been considering asking the Opensearch folks if they would be 
willing to separate their next/previous/first/last link relations out to 
a separate spec that could be made a working group draft.  The paging 
functionality they offer provides a solution to paging in the protocol 
and are generally useful across a broad variety of feed application 
cases.  Regardless, it would be very good to see these registered.

- James

James Holderness wrote:

>
> In case anyone is interested, the OpenSearch Response draft can be 
> found here:
>
> The rel values they support include next, previous (not prev), start 
> and end. They have a note next to each saying "This value is pending 
> IETF registration". Does that mean they've actually started some kind 
> of registration process or they're just hoping to do so at some point 
> in the future?
>
> Another issue worth noting is that their example RSS feed is also 
> using atom:link to provide this functionality.
>
> Robert Sayre wrote:
>

---

From: James M Snell <[email-masked]>
Date: Sun, 09 Oct 2005 21:03:48 -0700

I don't think not using the URI is a problem so long as the intent is to 
register the value and you make an attempt at standardization.  The 
problems arise when folks use names when they have no intention of 
standardizing or registering.

- James

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 13 Oct 2005 15:19:29 -0400

> cases.  Regardless, it would be very good to see these registered.

+1

    -joe

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Oct 2005 15:53:25 -0700

I've been considering moving feed history over to atom:link, but  
wanted to check with people who are currently using / referring to  
it, as well as with the RSS communities. Please give me a little time.

On 09/10/2005, at 9:06 PM, James M Snell wrote:

> willing to separate their next/previous/first/last link relations  
> out to a separate spec that could be made a working group draft.   
> The paging functionality they offer provides a solution to paging  
> in the protocol and are generally useful across a broad variety of  
> feed application cases.  Regardless, it would be very good to see  
> these registered.
>
> - James
>
> James Holderness wrote:
>
>
>
>>
>> The rel values they support include next, previous (not prev),  
>> start and end. They have a note next to each saying "This value is  
>> pending IETF registration". Does that mean they've actually  
>> started some kind of registration process or they're just hoping  
>> to do so at some point in the future?
>>

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Oct 2005 16:18:29 -0700

Excellent.  If this works out, there is an opportunity to merge the 
paging behavior of Feed History, OpenSearch and APP collections into a 
single set of paging link relations (next/previous/first/last).

Mark Nottingham wrote:

>> The paging functionality they offer provides a solution to paging  in 
>> the protocol and are generally useful across a broad variety of  feed 
>> application cases.  Regardless, it would be very good to see  these 
>> registered.
>>
>> - James
>>
>> James Holderness wrote:
>>
>>
>>
>>>
>>> pending IETF registration". Does that mean they've actually  started 
>>> some kind of registration process or they're just hoping  to do so 
>>> at some point in the future?
>>>

---

From: Eric Scheid <[email-masked]>
Date: Fri, 14 Oct 2005 11:58:36 +1000

> single set of paging link relations (next/previous/first/last).

'first' or 'start'?

Do we need to define what 'first' means though?  I recall a dissenting
opinion on the wiki that the 'first' entry could be at either end of the
list, which could surprise some.

e.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 13 Oct 2005 21:01:14 -0600

> list, which could surprise some.

Yeah, that's a good question.  Maybe calling them "top" and "bottom"  
would work better.  Considering that the convention is to put the  
newest entry at the top of a feed document, "top" might be more  
intuitively understandable as being the new end.  You might also  
rename "next" and "previous" (or is it "previous" and "next"?) to  
"down" and "up".  There's SOME chance of that getting confused with  
hierarchical levels, but I could live with that.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 14 Oct 2005 05:23:13 +0200

* Antone Roundy <[email-masked]> [2005-10-14 05:10]:
> >Do we need to define what 'first' means though?  I recall a
> >dissenting opinion on the wiki that the 'first' entry could be
> >at either end of the list, which could surprise some.
> 
> Yeah, that's a good question. Maybe calling them "top" and
> "bottom" would work better. Considering that the convention
> is to put the newest entry at the top of a feed document,
> "top" might be more intuitively understandable as being the
> new end. You might also rename "next" and "previous" (or is
> it "previous" and "next"?) to "down" and "up". There's SOME
> chance of that getting confused with hierarchical levels, but
> I could live with that.

'inaugural' and 'latest'? :-)

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

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 14 Oct 2005 00:01:50 -0400

> list, which could surprise some.

Eric,
   It's like deja-vu all over again.

 http://bitworking.org/news/Atom_Auto_Sub_How_To

   :)

   -joe

---

From: Eric Scheid <[email-masked]>
Date: Fri, 14 Oct 2005 14:15:36 +1000

> http://bitworking.org/news/Atom_Auto_Sub_How_To

I'd forgotten about that, I was only remembering the wiki.

I still think it odd that one could traverse both "prev" and "next" from the
"start". In the context of paging link relations (first/next/prev/last) I
would've thought that 'first' and 'last' are boundaries, and only the 'last'
boundary would shift over time as more is added.

e.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Oct 2005 07:48:32 -0700

The approach I took in -04 was to say that the pseudo-ordering  
introduced by the mechanism was ONLY meaningful for the purposes of  
reconstituting the feed; it's still up to the feed itself to  
determine what the ordering of entries means (or doesn't). That  
avoids a lot of problems, although it does require some careful wording.

Also -- I'd think that the "last" link is already covered by "self,"  
no? If not, there's some pretty serious confusion about what 'self'  
means.

On 13/10/2005, at 8:01 PM, Antone Roundy wrote:

>> dissenting
> "bottom" would work better.  Considering that the convention is to  
> put the newest entry at the top of a feed document, "top" might be  
> more intuitively understandable as being the new end.  You might  
> also rename "next" and "previous" (or is it "previous" and "next"?)  
> to "down" and "up".  There's SOME chance of that getting confused  
> with hierarchical levels, but I could live with that.
>
>
>

---

From: Eric Scheid <[email-masked]>
Date: Sat, 15 Oct 2005 01:27:34 +1000

> no? If not, there's some pretty serious confusion about what 'self'

What if a magazine publishes articles only once per month, each month's
entries are all in one feed document, each feed document with unique URIs,
and the public 'self' URI simply redirects to the last feed document.

That is:

    http://example.com/monthly/current.atom

redirects to 

    http://example.com/monthly/2005-10.atom

Of course you can find the 'last' archive via the 'self' URI, but that
doesn't make them the same thing. If you were paging through using 'next',
how would you know you've reached the 'last' ... apart from running out of
'next' links, and apart from separately retrieving the 'self' URI and noting
the eventual URI handed back so you can compare against the one in 'last'.

Why would anyone want to know the 'last' link? One use case is that one
could take note of the 'last' URI, and then later find out what the 'last'
URI now is ... and if they are different then obviously more has been added
and it's time to go fetch.

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 14 Oct 2005 17:52:00 +0200

* Eric Scheid <[email-masked]> [2005-10-14 17:35]:
> Why would anyone want to know the 'last' link? One use case is
> that one could take note of the 'last' URI, and then later find
> out what the 'last' URI now is ... and if they are different
> then obviously more has been added and it's time to go fetch.

If you really want this, don’t forget to to legislate this
expectation. Otherwise some people may devise clever (or
“clever”) stuff which breaks this expectation. Your example of
breaking

    atom:link[@rel='self']/@href = atom:link[@rel='last']/@href

is a perfect demonstration of how someone may do something legal
that may break (naïve?) expectations.

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Fri, 14 Oct 2005 17:09:00 +0100

Mark Nottingham wrote:
> The approach I took in -04 was to say that the pseudo-ordering  introduced 
> by the mechanism was ONLY meaningful for the purposes of  reconstituting 
> the feed; it's still up to the feed itself to  determine what the ordering 
> of entries means (or doesn't). That  avoids a lot of problems, although it 
> does require some careful wording.

The ordering of the entries may not matter, but the ordering of the 
documents does. Starting with the active feed document, you need to know 
whether you should be following a series of "prev" links or "next" links in 
order to traverse the archives back through time. While your feed history 
spec used "prev" for that purpose, previous implementations of atom:link 
appear to have used "next".

I can see the justification for both choices and don't particularly mind 
either way. However if the final decision is to go with "prev" rather than 
"next" I think there should at least be a note to the effect that there may 
be existing implementations of Atom 0.3 using "next".

> Also -- I'd think that the "last" link is already covered by "self,"  no? 
> If not, there's some pretty serious confusion about what 'self'  means.

I was going to suggest that initially but I don't think it's strictly true. 
The spec says that "self" identifies a resource *equivalent* to the 
containing element. Considering that an archived document and the active 
feed document will quite likely have no entries in common I think it's a bit 
of a stretch to claim them equivalent. "Derived" would be a better 
relationship IMHO.

Not that I care, mind you. Just pointing out that such a usage may conflict 
somewhat with the spec.

Regards
James