RFC4287 has no concept of a "Collection". Collections are only introduced by Atompub. And if you look at the Atompub spec, there's no mention of atom:updated at all, so it's still entirely up in the air and subject to individual interpretation.
- James Eric Larson wrote: > Hi, > > On 8/23/07, James M Snell <[EMAIL PROTECTED]> wrote: >> 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. >> > > I would actually assume that it means the last time the collection as > a whole was updated. > > Simply from a logical perspective, if I want to see when the specific > feed was updated, it seems the atom:updated elements in the entries > can tell me that. Also, the atom:updated in the in the feed seems to > be similar to the atom:title of the feed, which I would assume would > have meaning relative to the collection and not simply the current > feed. For example, if I were implementing paging and the using a GET > variable: > > http://host.com/blog/feed/index.atom?page=3&limit=10 > > It seems logical that the collection information found in the feed > would be consistent across each paged entry. > > I mention all this simply b/c as James says, it is not entirely clear, > so my suggestions above are really just my two cents as to what folks > should do as a best practice. > > What do you all think? > > Eric > >> - 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/ >>> >>> >>> >> >
