On 2008-02-12 03:32, you wrote: > Bill de hOra wrote: > > Antone Roundy wrote: > >> 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. > > Not that there is an explicitly worded statement, but one would > consider using the same ID in different archive documents of one feed. > This is how the example in section 4 of RFC 5005 illustrates archive > documents. In Antone's words, these form a chain of archive documents > corresponding to a large feed. > > However, neither RFC 5005 nor RFC 5023 specifically state a requirement > on the id of the partial lists of a collection, or the pages of a feed. > In the absence of such a requirement, there cannot be any expectation > that they are all identified identically. Given this, it seems > perfectly logical to treat the id of a feed as a container aka feed > document identifier, and that different containers aka feed documents > (even when used in concert to represent a single feed) are better off > using their own identifiers. > > Also, given that there is no requirement that the various physical > views of a feed -- pages, archives, subsets derived through queries, > etc -- carry a single id, the atom:id element inside a feed loses any > meaning beyond a "container identifier". Applying this I conclude that > there is no requirement that the GData query feed have the same atom:id > as the one present in the collection feed. > > > 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. > > Bill seems to suggest that seen in the context of XMPP, a feed document > as a container is equivalent to a stream. Therefore, the stream > identifier, seen as the session key, does not have any permanence. Not > only that, there cannot be correlation between the identifiers of > different streams. > > However, feeds are used for a one-to-many communication whereas XMPP > streams are used for one-to-one communication, IMHO. It helps to have > the same id be used for different feed documents, even those obtained > at different times from the same URL. > > * Isn't this how feed aggregators seem to track the evolution of a > feed's contents over time and to present a historical view of > that feed? > * If not, is there a standards-based means of tracking this > evolution? > > It would help if the authors of RFC 5005 or 5023 can clarify if there > is a reason why these specs do not deal with the issue of atom:id in > pages, archive documents, and partial lists.
The very first question that came to my mind after reading RFC 5005 was ‘but what about the atom:id?’ I thought it may have been overlooked in the specifications. -- Daniel Aleksandersen <[EMAIL PROTECTED]> http://www.opensourcenotebook.com/
