James Holderness wrote: > > Mark Nottingham wrote: >> 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". > > 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.
Compare their atom:[EMAIL PROTECTED]"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:[EMAIL PROTECTED]"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:[EMAIL PROTECTED]"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:[EMAIL PROTECTED]"self"] is sufficient, there's no need for a "next". -- Thomas Broyer
