On Feb 11, 2008 8:32 PM, Nikunj Mehta <[EMAIL PROTECTED]> 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.
I can agree with the "cannot be any expectation" part of this, given the general vagueness of specification around feed-level atom:id; however, I'd observe that "not required to use the same atom:id" due to lack of clarity is distinctly different from "thus should not use the same atom:id". > 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. > I'm not necessarily following the logic. See above statements. A use case for the benefits of sharing an atom:id (being able to tell that all feed documents derive from the same source collection) has been stated, and I suspect was the motivation for the sample usage in RFC5005. If this benefit is perceived to exist in other contexts as well, why would it not be applicable as well? Regarding the argument that "filtering" is somehow different, isn't pagination or archival just filtering of a different type, i.e. by sequential order and/or by time rather than by other attributes of the feed content? I've not yet seen a strong argument for why making them different is beneficial or helpful or why making them the same is harmful, but maybe I'm just being missing something. Finally, I want to be clear that in stating the our implementation, I wasn't try to impose a particular generalized interpretation on feed id usage. I was just sharing experience and rationale as an implementor to inform the discussion. YMMV. Cheers! -- Kyle > 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. See above. Stating that something doesn't have to be done a particular way is not equivalent to saying it should not. > > 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. > Again, I don't see this as an argument against having the same atom:id. It just informs that doing so isn't useful (but is not harmful) in that particular context. > 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. > I think this particular aspect isn't open for debate, at least to me. It certainly seems significantly useful for the same feed retrieved repetitively from the same url to have a constant atom:id. > * 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. > > Nikunj > >
