There is the Feed Rank extension which can be used to specify the order for entries but that's still a work in progress and has been a very low priority for me.
IMHO, you should base this entirely on atom:id and atom:updated. If you find another entry with a duplicate atom:id and a newer atom:updated, it takes precedence. If you find an entry with a duplicate atom:id and an older or equal atom:updated, the one you currently have takes precedence. If you want more granularity, look for app:edited elements. - James Mark Nottingham wrote: > > I haven't had any feedback on the possible change below. Does anyone > want to see things move in this direction? > > Cheers, > > > On 2006/10/11, at 10:06 PM, Mark Nottingham wrote: > >>> 1. I think your document might need to address what's supposed to happen >>> if duplicate items are discovered when trolling through the paged info. >>> Newer replaces older? (That makes the most sense to me) Although I guess >>> the argument might be, "what's an 'item'?". >> >> I started going down that road in early drafts, but backed away from >> it when it started looking like a rat hole. :) >> >> To allow FH to normatively specify what to do with duplicates, you >> have to figure out the ordering of entries, so you can determine their >> relative precedence. Since Atom doesn't have any explicit ordering, FH >> would need to either assume ordering semantics implicitly, or doing >> something explicit in an extension. >> >> In the paged case, this seems like a tall order, because it's totally >> context-dependent; e.g., if you have OpenSearch or GData results, or >> orders for launching the missiles that are paged, and you happen to >> get a duplicate, the right thing to do may be very different. >> >> In the archived case, it's a little easier, because we're already >> inferring that the pages closes to current do have precedence, so we >> just need to figure out what to do about duplicates in the same feed >> document. >> >> I could see making the implied page-by-page precedence for Archived >> feeds in section 4 explicit. It would also be easy to add text saying >> that relative precedence in the same feed document can be determined >> by any extension that defines ordering, defaulting to the update time >> of the entries (or document order, topmost first? I think this is what >> most people do, but it seems contrary to the spirit of the Atom spec). >> I'm not crazy about actually defining an ordering extension (is one in >> progress? James?) in FH. > > > -- > Mark Nottingham http://www.mnot.net/ > >
