Many, if not most, aggregators consider RSS and Atom feeds to be a group of entries greater than those in the most recent representation. This proposal codifies and formalises that practice.
Just Proposed (will she accept?)
If we don't specify this, Atom will be unusable for many applications; Feed authors won't have a reasonable guarantee of how their entries will be treated, and there won't be any mechanism for catching up on missed entries.
In the 'Managing Feed State' section of the format document, add:
Feed State Model
An Atom Feed is conceptually a set of entries; each entry is identified by its 'id' attribute and represents the state of one Web resource. That is, each entry appears in the feed precisely once, and there is no default ordering of the entries in it.
An Atom Feed Document may or may not contain the complete set of entries in its associated Atom Feed; Most Atom Feed Documents can be thought of as a snapshot of it, containing the most recent changed entries. If these snapshots are unioned with those entries that are already known from past Atom Feed Documents, the complete Atom Feed can be reconstructed.
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.
This specification does not provide a means of deleting entries from an Atom Feed; however, this facility may be provided in an extension.
Reconstructing Feed State
To be able to faithfully reconstruct a feed, consumers need to either be aware of all changes that take place over time, or need to be able to obtain the complete state of the feed.
For example, if a consumer polls once a day, but there are three separate Atom Feed Documents updating that Atom Feed published during that day, it will only be aware of the last Atom Feed Document and the changes therein.
To locate previous Atom Feed Documents, consumers can follow the atom:link element in the atom:head with a @rel of "prev", which contains a persistent URI for the previous Atom Feed Document associated with this feed. 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:link[@rel='this'] element), a consumer can reconstruct the state of a feed reliably.
Atom Feed Documents SHOULD contain //atom:head/atom:link[@rel='this'] AND //atom:head/atom:link[@rel='prev']
Atom consumers MUST warn users when they do not have the complete state of a feed (e.g., by documenting that they are not capable of doing so; by alerting the user that an Atom Feed Document is unavailable, or inserting pseudo-entries that inform the user that some entries may be missing). Note that publishers are not required to make all previous Atom Feed Documents available.
Requires additions and changes to the list of link/@rel values; 'this' will need to be added, and 'prev' might need to be adjusted.
It may be useful to include information about detecting changed entries and sorting entries.
It may be useful to include a mechanism for deleting entries, but that should probably be in a separate Pace.
This proposal does allow other mechanisms for synchronising state to be defined as extensions; it's not exclusive, just a simple, workable lowest-common-denominator way to do it.
Consumers aren't required to keep state of feeds around; they're just required to warn people that they don't show the entire feed (e.g., in their documentation or product details). This means that the Atom aggregators built into many browsers today will be conformant, as long as they say that they have reduced functionality; they don't offer the complete Atom Feed.
The language needs to be adjusted in several places, e.g., to align with the rest of the text, to place normative requirements, etc. If accepted, the editors can use license to do so.