How about adding:
To "complete feeds":
---8<---
This specification does not address duplicate entries or entry
ordering in complete feeds.
--->8---
To "paged feeds":
---8<---
Note that this specification does not address duplicate entries or
entry ordering in paged feeds.
--->8---
To "archived feeds":
---8<---
If duplicate entries are present in an archived feed, the most
recently updated entry SHOULD replace all earlier entries. If
duplicate entries have the same update time, and they are obtained by
different feed documents, the entry sourced from the most recently
updated feed document SHOULD replace all other duplicates of that entry.
In Atom archived feeds, two entries are duplicates if they have the
same atom:id element. The update time of an entry is determined by
its atom:updated element, and likewise the update time of a feed
document is determined by its feed-level atom:updated element.
In RSS2 archived feeds, two entries are duplicates if they have the
same guid element. The update time of an entry is not available,
unless an appropriate extension is present. The update time of a feed
document is determined by the channel-level pubDate element.
This specification does not address entry ordering in archived feeds.
--->8---
This will require some tweaks to the algorithm in Appendix B as well.
On 2006/11/13, at 1:59 PM, James M Snell wrote:
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/
--
Mark Nottingham http://www.mnot.net/
