Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Nov 2006 13:25:43 -0800

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/

---

From: James M Snell <[email-masked]>
Date: Mon, 13 Nov 2006 13:59:40 -0800

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:
>>> 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
>> I started going down that road in early drafts, but backed away from
>> it when it started looking like a rat hole. :)
>>
>> 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.
>>
>> 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.
>>
>> 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.
> 
> 
> --

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Nov 2006 21:23:35 -0800

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:

>>> their
>>> totally
>>> saying