On 2008-02-10 02:01, you wrote: > Antone Roundy wrote: > > Bill de hOra wrote: > >>> But Bill, it's not two different feeds, it's two different views of > >>> the same feed -- an archive view, and a "latest entries" (a.k.a. > >>> "sliding window") view. Thus the shared atom:id IS "globally > >>> unique on a per my feed basis", just not on a per feed DOCUMENT > >>> basis. > >> > >> What breaks if they have two different ids?
I am wondering what does break if they have the same ID? > > Perhaps nothing "breaks", but it's just a little odd to have the same > > entries originating from two different feeds. > > I don't find that odd; whereas I might find the same entry originating > from two different authors odd. I agree with Antone. It should be the same ID. If the point of the ID is to identify the source (collection, feed, whatever you want to call it) rather than the document (the feed file). > > I presume neither > > document is going to use an atom:source element to show that they're > > not the originator of the entries, so it looks like you have two > > feeds and are erroneously using duplicate IDs for their entries. > > If nothing breaks, how can it be an error? > > > And by the way, is the archive document one monolithic document > > containing everything, or is it going to be split into a chain of > > archive documents? If it's a chain, surely you wouldn't give each > > document in the chain it's own ID, right? > > Why not? > > > The reason to use the same ID in both cases is to show that they both > > represent the same feed -- that the one is the archive of the other. > > Try running Atom over XMPP. I think it might change how you view what a > feed 'is'. It did for me; I have a hard time explaining how, but it > seems that feeds are a workaround for HTTP, which doesn't have > containers or iterators. -- Daniel Aleksandersen <[EMAIL PROTECTED]>
