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/ > > > > > > > >
