Subject: Paged Feeds Question

From: "Becker, Matthew R" <[email-masked]>
Date: Mon, 12 Nov 2007 14:39:02 -0500

When a feed is paged according to RFC 5023 and someone requests a
particular page in the feed, should the ID element and "self" link
include the page number?

If they should include the page number, should the first page of the
feed include the page number in the ID and Self URIs as well?

Thanks,

Matt.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 12 Nov 2007 21:16:08 +0100

* Becker, Matthew R <[email-masked]> [2007-11-12 20:55]:
> When a feed is paged according to RFC 5023 and someone requests
> a particular page in the feed, should the ID element and "self"
> link include the page number?

No.

Most certainly the `self` link should not, as it’s supposed to be
the address that aggregators subscribe to; you’re very unlikely
to want aggregators to subscribe to the 10th page of a paged
feed.

For the feed ID it’s not always quite clear-cut when it should be
the same and when it should differ, but in this particular case
it is obviously the same feed and hence should have the same ID.
(Note well that the feed ID may well be entirely opaque with no
way to include arbitrary information, such as a UUID.)

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

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Nov 2007 12:44:33 +1100

> For the feed ID it¹s not always quite clear-cut when it should be

Note too that the feed ID is the way you know that the page of atom entries
retrieved from [1] is from the same feed as the page of atom entries
retrieved from [2].

e.

[1] some opaque URL, details not important
[2] some other opaque URL, which apart from and despite being opaque doesn't
otherwise suggest any relationship to [1] at all

---

From: "Franklin Tse" <[email-masked]>
Date: Tue, 13 Nov 2007 18:27:11 +0800

However, RFC 5005 does not say that the atom:feed/atom:id should be the same 
in the same set of paged feeds/archived feeds.

It only says:

   A paged feed is a set of linked feed documents that together contain
   the entries of a logical feed, without any guarantees about the
   stability of each document's contents.

   An archived feed is a set of feed documents that can be combined to
   accurately reconstruct the entries of a logical feed.

In section 4.2.6 of RFC 4287:

   The "atom:id" element conveys a permanent, universally unique
   identifier for an entry or feed.

   When an Atom Document is relocated, migrated, syndicated,
   republished, exported, or imported, the content of its atom:id
   element MUST NOT change.  Put another way, an atom:id element
   pertains to all instantiations of a particular Atom entry or feed;
   revisions retain the same content in their atom:id elements.  It is
   suggested that the atom:id element be stored along with the
   associated resource.

   The content of an atom:id element MUST be created in a way that
   assures uniqueness.

In section 2 of RFC 4287:

   This specification describes two kinds of Atom Documents: Atom Feed
   Documents and Atom Entry Documents.

   An Atom Feed Document is a representation of an Atom feed, including
   metadata about the feed, and some or all of the entries associated
   with it.  Its root is the atom:feed element.

It looks that each Atom feed document should have its own id in RFC 4287...

-Franklin

--------------------------------------------------
From: "Eric Scheid" <[email-masked]>
Date: Tuesday, 13 November, 2007 09:44
To: "Atom Syntax" <[email-masked]>
Subject: Re: Paged Feeds Question

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Nov 2007 22:28:53 +1100

> It looks that each Atom feed document should have its own id in RFC 4287...

hmmm ... no, because atom:id at the feed level would then be data in the
feed document, not metadata about the logical feed. The value of atom:id is
the id of the feed resource, which then has parts of itself instantiated in
atom feed documents.

> RFC 5005 

that refers to the logical entry/feed resource, not various representations
and instantiations of that resource, IMHO.

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 13 Nov 2007 12:26:50 +0100

> It looks that each Atom feed document should have its own id in

I don’t see how that sort of conclusion can be supported by the
very spec section you quoted yourself:

    When an Atom Document is relocated, migrated, syndicated,
    republished, exported, or imported, the content of its
    atom:id element MUST NOT change. Put another way, an atom:id
    element pertains to all instantiations of a particular Atom
    entry or feed; revisions retain the same content in their
    atom:id elements.

I think that needs to inform a reading of the section you quoted
from RFC 5005:

    A paged feed is a set of linked feed documents that together
    contain the entries of a logical feed, without any guarantees
    about the stability of each document's contents.

    An archived feed is a set of feed documents that can be
    combined to accurately reconstruct the entries of a logical
    feed.

It seems relatively clear to me that “all instantiations of a
particular Atom feed” in RFC 4287 and “a logical feed” in
RFC 5005 refer to the same concept.

And so while the latter may say nothing about feed IDs, it seems
to me that an intent pretty strongly implied.

The problem is, of course, that this is very much a case of “I
know it when I see it”: what constitutes a logical feed is not
mechanically decidable. A spec can therefore not make any potent
mandates about such issues, and is reduced to vague language.

But vague language doesn’t imply an absence of intent; it merely
means that the intents in question defy precise codification.

Of course, at the cost of writing software that does nothing very
useful, you can insist on a literal reading of the letter of the
spec.

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Tue, 13 Nov 2007 11:57:40 -0000

I have to agree with Eric and Aristotle.

>   identifier for an entry or feed.

Note that says "feed", not "feed document".

>   with it.

That tells us that a feed *document* can be a representation of *some* of 
the feed. From that we can deduce that two feed documents could represent 
two different parts of the same feed. Since the atom:id is unique to the 
feed, not the feed document, both such documents should share the same id.

Regards
James

---

From: "Franklin Tse" <[email-masked]>
Date: Tue, 13 Nov 2007 21:05:01 +0800

Thank all of you for the explanations.

I have another question about the Atom self link.

In RFC 4287,

   o  atom:feed elements SHOULD contain one atom:link element with a rel
      attribute value of "self". This is the preferred URI for
      retrieving Atom Feed Documents representing this Atom feed.

So, does this mean that the atom:link with rel="self" should have a href to 
the first page of a paged feed or the subscription document of an archived 
feed?

-Franklin

--------------------------------------------------
From: "James Holderness" <[email-masked]>
Date: Tuesday, 13 November, 2007 19:57
To: "Atom Syntax" <[email-masked]>
Subject: Re: Paged Feeds Question

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 13 Nov 2007 19:56:19 +0100

* Franklin Tse <[email-masked]> [2007-11-13 14:20]:
> Does this mean that the atom:link with rel="self" should have
> a href to the first page of a paged feed or the subscription
> document of an archived feed?

By subscription document, do you mean the subscribable, public
version of the feed? If so, yes, it’s probably a good idea for
the `self` link to that one, not the paged feed. There is no
intent here the way there is with feed IDs, though. It’s just a
matter of pragmatism.

It’s clear that you don’t want aggregators subscribing to any
page of an archive feed, ever.

It’s also pretty clear why you don’t want aggregators subscribing
to the 10th page of a collection feed: they might have to wait a
very long time until they see entries that were posted very
recently.

As for whether aggregators should subscribe to a collection feed
or the public feed, note well that collection feeds SHOULD be
ordered by app:edited – so aggregators subscribed to a collection
feed might frequently find it changed without any new entries
having been posted. It’s even conceivable that the opposite
happens – that editing churn pushes newly posted entries off the
first page of the feed in less than a reasonable aggregator
polling interval, so that the aggregator misses them completely.

So overall, it is best for aggregators to subscribe to the public
published feed. You are free to make a different decision on a
case-by-case basis though.

Regards,

---

From: Eric Scheid <[email-masked]>
Date: Wed, 14 Nov 2007 07:56:29 +1100

> the first page of a paged feed or the subscription document of an archived

yes.

e.

---

From: "Franklin Tse" <[email-masked]>
Date: Wed, 14 Nov 2007 14:38:21 +0800

Since RFC 5005 does not clearly define if atom:feed/atom:id should change 
and which feed should atom:feed/atom:link[@rel="self"] point to, feed 
publishers may not know what they should do, and implementations may vary. I 
think the situation can be improved if the Feed Validator adds some 
recommendations.

Based on the discussions before, the following rules should be added:

1. If first, last, previous, next, prev-archive, next-archive or current is 
found, issue a notice reminding the publisher that all of the feed documents 
of a paged feed or an archived feed should share the same feed ID

2. If the href of a "current" link is not equal to the href of the "self" 
link, issue a warning or a notice

However, Sam's archived feed is not following the recommendations above:

http://intertwingly.net/blog/archives/index.atom
http://intertwingly.net/blog/archives/2007/10/index.atom

-Franklin

-------------------------------------------------
From: "Eric Scheid" <[email-masked]>
Date: Wednesday, 14 November, 2007 04:56
To: "Atom Syntax" <[email-masked]>
Subject: Re: Paged Feeds Question

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Nov 2007 09:34:50 +1100

My recollection of discussions during 5005 was that we had to come up  
with "current" precisely because "self" was ambiguous. People may  
have a reason for advertising the archive document's URI in "self",  
and I don't see what the utility of repeating it is.

YMMV.

Cheers,

On 14/11/2007, at 5:38 PM, Franklin Tse wrote:

>
> Since RFC 5005 does not clearly define if atom:feed/atom:id should  
> change and which feed should atom:feed/atom:link[@rel="self"] point  
> to, feed publishers may not know what they should do, and  
> implementations may vary. I think the situation can be improved if  
> the Feed Validator adds some recommendations.
>
> 1. If first, last, previous, next, prev-archive, next-archive or  
> current is found, issue a notice reminding the publisher that all  
> of the feed documents of a paged feed or an archived feed should  
> share the same feed ID
>
> 2. If the href of a "current" link is not equal to the href of the  
> "self" link, issue a warning or a notice
>

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