Good question. Unfortunately the spec does not give a very clear answer. The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant
Given that the RFC does not really have any notion of a "logical feed", the only reasonable interpretation I think we can make is that it applies only to *this* feed document. - James Mark Nottingham wrote: > > Does atom:updated apply to *this* feed document, or the whole, logical > feed? > > > On 24/08/2007, at 1:06 AM, Daniel E. Renfer wrote: > >> Would it be safe to assume that if I retrieve two pages of a paged feed, >> and the atom:updated element for the feed is unchanged then I am indeed >> seeing a complete history of that feed? >> >> If I retrieve page 1, record the updated time, and retrieve page 2 and >> the updated time has changed, then I know new entries have been added to >> the feed since I got page 1. There may be some entries in page 2 that I >> previously saw in page 1. (The ones that have overflown to the next >> page) I'll have to re-retrieve page 1 to get the new entries. >> >> If I retrieve page 2 first, and then get page 1, and the updated value >> has changed, I know that I am missing some entries. They were on page 1 >> when I first got page 2, but are now on page 2. (or higher) I will have >> to re-retrieve the next page(s) until I find an entry I recognize. >> >> If the updated value is unchanged, then nothing has been added, removed, >> or modified in the feed. I can consider my view of the feed to be >> complete. >> >> Am I correct in this assumption? >> >> Thomas Broyer wrote: >>> 2007/8/21, Nikunj Mehta: >>>> Thomas Broyer wrote: >>>>> 2007/8/21, Nikunj Mehta: >>>>> >>>>>> §10.1 of AtomPub I-D expects collection partial lists aka pages to be >>>>>> /lossless/. >>>>>> >>>>> Seems like we don't have the same definition of lossless then... >>>>> >>>> Allow me to clarify. A lossless paging is the following (this is my >>>> interpretation of §10.1 of AtomPub I-D): >>>> >>>> The partial list of entries obtained by GETting the collection's >>>> URI >>>> combined with partial lists obtained by following the rel="next" >>>> links in each of those partial lists MUST provide the snapshot of >>>> all of a collection's entries *as of the time *when the server >>>> responded to the GET request on the collection URI. >>> >>> OK, so we don't have the same interpretation. It means this means >>> clarification in the spec (is it too late?). >>> >>>> On the contrary lossy paging occurs when there is no such guarantee, >>>> i.e., navigating between partial lists might produce the same entry >>>> twice or more, might skip an entry completely because it >>>> "disappeared in >>>> the boundary between pages". >>> >>> Yup. >>> >>>>> Partial lists in AtomPub are subject to the following constraint: >>>>> The first such partial list returned MUST contain the most >>>>> recently >>>>> edited member Resources and MUST have an atom:link with a "next" >>>>> relation whose "href" value is the URI of the next partial list >>>>> of the >>>>> Collection. This next partial list will contain the next most >>>>> recently >>>>> edited set of Member Resources (and an atom:link to the following >>>>> partial list if it exists). >>>>> >>>> If I am interpreting this right (without any formal model of course), >>>> then "next" implies the immediately "next most recently edited". To me, >>>> that means lossless. >>> >>> As partial lists are not defined to be "stable", they might be >>> changing over time. At the time you retrieve the first partial list, >>> the second partial list contains the "next most recently edited". But >>> between the retrieval of the first partial list and the time you >>> retrieve the second one, this one might have changed. >>> >>>> I respectfully disagree with this interpretation per my argument above. >>>> If the definition of partial lists and paging results in collection >>>> feeds being lossy, then how would we guarantee any synchronization of >>>> paged collections? >>> >>> You cannot guarantee synchronization without an atomic operation or >>> paging a snapshot. Requiring servers to create "paged snapshots" (i.e. >>> as per your interpretation of atompub-protocol-17) would have too much >>> implications: servers would need to remember each and every "edit" >>> (app:edited) of all the entries. >>> >>> The "partial list" thing is the Simplest Thing That Could Possibly >>> Work. If you want a reliable synchronization, then either: >>> 1. use another mechanism (RFC3229 w/ Feeds?) >>> 2. re-start synchronization from the Collection URI partial list >>> until you no longer need to follow the rel="next" link >>> >>>> Sorry I have come a little late to the feed history I-D party, but it >>>> looks like this spec is not strongly consistent with AtomPub (and the >>>> fact that the two don't even refer to each other's existence stinks, >>>> IMHO). >>>> >>>> Furthermore, can someone point out which RFC or I-D defines link >>>> rel="first", link rel="last", link rel="next" and link rel="previous"? >>> >>> http://www.iana.org/assignments/link-relations.html says its Feed >>> History. >>> >> > > > -- > Mark Nottingham http://www.mnot.net/ > > >
