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/
