On Monday, January 24, 2005, at 06:09 PM, Joe Gregorio wrote:
I am +1 on the //atom:head/atom:[EMAIL PROTECTED]'prev'], but -1 on //atom:head/atom:[EMAIL PROTECTED]'wholefeed'] and -1 on any of the verbage that makes demands on clients, for example, "Atom consumers MUST warn users when they do not have the complete state of a feed "
Agreed, agreed and agreed.
"When a new Atom Feed Document is received by a consumer, the entries in it are compared to those that are already known to belong to the same Atom Feed, in reverse document order (that is, starting with the last entry in the Atom Feed Document and working towards the first). If an entry from the document has the same 'id' attribute as an existing entry, the metadata associated with it replaces that currently associated with the entry completely. Any existing metadata, whether or not present in the new entry, is removed."
I think this is beyond the scope of the specification. First, the "reverse document order" part is unnecessary and inappropriate. Second, the client may keep the history of an entry--we shouldn't be mandating that the old metadata be discarded.
"By following such links progressively backwards and incorporating the changes in each associated Atom Link document, until it encounters a link to a document it already has seen (as identified by the //atom:head/atom:[EMAIL PROTECTED]'this'] element), a consumer can reconstruct the state of a feed reliably."
I'm not sure I'm in favor of this method. If, for example, the "sliding window" into one's feed contains 15 entries, and the "prev" link points to the prior 15 entries, unless one polls when a multiple of 15 entries have been added, you'll never see the same batch of entries you saw last time. Of course, feeds could be implemented in a way that avoided this problem...and I'm not sure I can think of a better method off hand. If for example you were to keep going backward till one saw an entry/id they'd seen before, you might stop too early if an entry had been altered and moved nearer the top of the feed. If you were to try to avoid this mistake by checking entry/updated for a change, you could still fail if the publisher decided not to bump its value (I for one would not change the order of entries without changing updated, but that's not to say others won't).
