Subject: Next and Previous

From: Alan Gutierrez <[email-masked]>
Date: Mon, 3 Oct 2005 16:27:43 -0400

What is the proper way to indicate the next chunk of articles in
    the feed? Is it link[@related] and if so what value for related?

    Where would someone put the offset?

    If this is not a good place for general Atom questions, please
    tell me which forum is more appropriate.

    Thank you.

--
Alan Gutierrez - [email-masked] - http://engrm.com/blogometer/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Oct 2005 16:57:51 -0700

Hi Alan,

Probably the closest thing to what you want is this proposal:
   http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
history-04.txt

It has "previous", but not "next".

Cheers,

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

---

From: "James Holderness" <[email-masked]>
Date: Wed, 5 Oct 2005 03:07:15 +0100

> It has "previous", but not "next".

It just occurred to me when reading this message that there may be some 
advantages to having a "next" link to go along with the "prev". I realise 
you don't need it in order to reconstruct a feed's history, but it does 
provide you with a certain amount of validation. For example, it's possible 
that someone could create an empty feed with nothing but their own title, 
author and copyright messages and a "fh:prev" link to someone else's feed in 
order to claim credit for a publication that wasn't their own. If an 
aggregator could rely on the existence of a "next" link it would be able to 
check for issues like that.

Of course, requiring all archived documents to have a "next" would cause 
problems when a new archive was created and the previously top archive would 
have to update it's "next" link to point to the latest archive document 
rather than the active feed document. So maybe not such a great idea. An 
alternative might be to make sure that feed-level titles, links and authors 
were an exact match across all documents in the history. Or maybe some kind 
of self link or root link that always pointed to the root document.

I don't know. Maybe there isn't a perfect solution. But isn't it at least 
worth mentioning something about this under "Security Considerations"?

Also, a minor point I noticed while reading the draft: the namespace prefix 
you use in most of the document is "fh" while the one in all the examples is 
"history". Technically still valid, but I figure you'd probably want them 
all to be the same.

Regards
James

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Oct 2005 22:45:04 -0700

On 04/10/2005, at 7:07 PM, James Holderness wrote:

> But isn't it at least worth mentioning something about this under  
> "Security Considerations"?

Good point; I'll try to come up with some text.

> Also, a minor point I noticed while reading the draft: the  
> namespace prefix you use in most of the document is "fh" while the  
> one in all the examples is "history". Technically still valid, but  
> I figure you'd probably want them all to be the same.

I did that on purpose :)

Cheers,

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 5 Oct 2005 09:12:46 +0200 (CEST)

James Holderness  wrote:
> provide you with a certain amount of validation. For example, it's
> possible that someone could create an empty feed with nothing but their
> own title, author and copyright messages and a "fh:prev" link to someone
> else's feed in order to claim credit for a publication that wasn't their
> own. If an aggregator could rely on the existence of a "next" link it
> would be able to check for issues like that.

Compare their atom:link[@rel="self" and
@type="application/atom+xml"]/@href, they'll point you to the "start" of
the "list", the one whose author and copyright apply. (Actually, author
and copyright should really appear in "history feed documents" as well,
aggregators shouldn't "apply copyright" from one document to other
documents linked from it).

If the "borrower" uses an atom:link[@rel="self"]/@href different from the
one found in history documents, aggregators should issue a warning. They
could also dereference the @href and see if they are redirected to the
final same URI.
If the "borrower" uses the same atom:link[@rel="self"]/@href as the one
found in history documents, aggregators should subscribe to that URI and
not the "borrower"'s one, so the "borrower" can't claim anything.

I think atom:link[@rel="self"] is sufficient, there's no need for a "next".

-- 
Thomas Broyer

---

From: "James Holderness" <[email-masked]>
Date: Wed, 5 Oct 2005 08:43:49 +0100

Thomas Broyer wrote:
> the "list", the one whose author and copyright apply.

On the whole I tend to agree, but since there isn't a "self" link in either 
of the RSS formats and Mark would like this extension to be format neutral, 
he would either have to introduce an equivalent element into the spec or 
strongly suggest that RSS feeds include a "self" atom:link. Technically it 
isn't even required that all Atom feeds have such a link, so either way it's 
something worth clarifying.

> (Actually, author

Technically yes, but try and imagine how an aggregator might handle that 
sort of thing. The feed may be made up of a collection of documents, but 
from the user's point of view it's all just one big feed. A copyright 
message is the sort of thing that would show up once in a properties dialog 
for the feed, or somewhere in the header or footer in a "newspaper" view. 
It's highly unlikely an aggregator would try and track multiple copyright 
messages and display them on a per item basis.

As for author, if you've got item-level author elements you should be ok, 
but if there aren't, the aggregator is quite likely to take the last 
feed-level author it received and apply it to all subsequent items. It can 
be argued that that's a bug, but it's not unreasonable to imagine than many 
aggregators might do such a thing unless explicitly told not to.

Regards
James

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 5 Oct 2005 10:29:53 +0200 (CEST)

James Holderness  wrote:
> On the whole I tend to agree, but since there isn't a "self" link in
> either of the RSS formats and Mark would like this extension to be format
> neutral, he would either have to introduce an equivalent element into the
> spec or strongly suggest that RSS feeds include a "self" atom:link.

Maybe one more reason to use an atom:link instead of fh:prev...

> Technically it isn't even required that all Atom feeds have such a link,
> so either way it's something worth clarifying.

Agreed.

> message is the sort of thing that would show up once in a properties
> dialog for the feed, or somewhere in the header or footer in a "newspaper"
> view.

Hmm, right.

> messages and display them on a per item basis.

atom:rights at feed-level don't apply to its entries, just to the feed as
it stands. If you want to grant/restrict rights at an entry-level, use the
entry-level atom:rights.

I can understand how an entry-level atom:rights could be presented to the
end-user, but I can't imagine how it could be done for the feed-level
atom:rights, given that it can change during the feed's "life". The only
solution I can see is to store feed metadata on an atom:source inside each
entry, so you can ask for the entry-level and feed-level atom:rights for
each entry in your aggregator.

> be argued that that's a bug, but it's not unreasonable to imagine than
> many aggregators might do such a thing unless explicitly told not to.

Aggregators are more likely to copy/paste de feed-level authors into each
entry and totally forget about feed-level ones.

-- 
Thomas Broyer

---

From: "James Holderness" <[email-masked]>
Date: Sat, 8 Oct 2005 06:03:18 +0100

> it stands. If you want to grant/restrict rights at an entry-level, use the

Ok, I missed that. For some reason I assumed atom:rights was just a 
feed-level element (probably thinking of RSS). However, according to the 
spec it's perfectly acceptable to use a feed-level rights element to grant 
rights at an entry-level (assuming all your entries are meant to have the 
same rights).

> each entry in your aggregator.

If I'm going to have to deal with rights on a per-entry basis, I think I'd 
probably just ignore the concept of feed-level rights. That's not to say I'd 
ignore the feed-level element altogether - I'd consider it a default to be 
used if there wasn't an atom:rights element at the entry-level. However, if 
they're both included I'd ignore the feed-level element. I don't think 
that's inconsistent with section 4.2.10 of the spec.

As for how this applies to the history extension:  if the first document 
retrieved contained a feed-level atom:rights element, but documents linked 
via fh:prev contained no rights (feed-level or entry-level), I would 
probably apply the rights from the first document rather than assigning no 
rights at all. Of course that's where the "security flaw" comes in, but 
perhaps that's my own fault.

> entry and totally forget about feed-level ones.

I'm not sure if you meant "totally forget about the entry-level ones". If 
that's the case, as a user I wouldn't be very pleased with the aggregator. 
Most blogs may only have one author per feed, but that's certainly not the 
case for all feeds. Group blogs, comment feeds, forums, mailing-lists, 
slashdot - there are plenty of cases where entry-level authors are used.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Sat, 08 Oct 2005 07:47:09 -0700

James Holderness wrote:

> feed-level element (probably thinking of RSS). However, according to 
> the spec it's perfectly acceptable to use a feed-level rights element 
> to grant rights at an entry-level (assuming all your entries are meant 
> to have the same rights).
>
Yeah, this is something I came up against with the license link rel 
extension as well.  If you're going to use the rights element, you 
really should have it on every individual entry as opposed to the feed 
level.

> If I'm going to have to deal with rights on a per-entry basis, I think 
> I'd probably just ignore the concept of feed-level rights. That's not 
> to say I'd ignore the feed-level element altogether - I'd consider it 
> a default to be used if there wasn't an atom:rights element at the 
> entry-level. However, if they're both included I'd ignore the 
> feed-level element. I don't think that's inconsistent with section 
> 4.2.10 of the spec.
>
The feed level element should be considered to apply to the feed; the 
entry level element should be considered to apply to the entry.  For 
example, if I produce an aggregated feed containing entries from 
multiple locations, I own the copyright on the feed, but the other 
authors own the copyrights on the entries.  The rights element should 
reflect that accordingly.

> As for how this applies to the history extension:  if the first 
> document retrieved contained a feed-level atom:rights element, but 
> documents linked via fh:prev contained no rights (feed-level or 
> entry-level), I would probably apply the rights from the first 
> document rather than assigning no rights at all. Of course that's 
> where the "security flaw" comes in, but perhaps that's my own fault.
>
I would not make this assumption.  Each feed/entry in the history SHOULD 
contain it's own rights element.  I would not default anything in this case.

- James

---

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

> example, if I produce an aggregated feed containing entries from multiple 
> locations, I own the copyright on the feed, but the other authors own the 
> copyrights on the entries.  The rights element should reflect that 
> accordingly.

Agreed. I just don't see myself being enthusiastic enough to provide that 
level of support in an aggregator. Throwing in a copyright message at the 
bottom of an entry is probably not too difficult. Anything more than that 
seems like way too much effort. I mean how many end-users are really likely 
to care about that sort of thing.

> contain it's own rights element.  I would not default anything in this 

Yeah, you're probably right. I was never convinced that was a good idea.

Regards
James