Re: Feed State [was: Work Queue Rotation #16]
This is now PaceNoFeedState; http://www.intertwingly.net/wiki/pie/PaceNoFeedState On Jan 31, 2005, at 3:46 PM, Mark Nottingham wrote: x. Managing Feed State Atom Processors MAY keep state (e.g., metadata in atom:head, entries) sourced from Atom Feed Documents and combine them with other Atom Feed Documents, in order to facilitate a contiguous view of the contents of the feed. The manner in which Atom Feed Documents are combined in order to reconstruct a feed (including methods of identifying duplicate entries, updating metadata, and dealing with missing entries) is out of the scope of this specification, but may be defined by an extension to Atom. -- Mark Nottingham http://www.mnot.net/
Re: Feed State [was: Work Queue Rotation #16]
On 4/2/05 4:03 PM, Mark Nottingham [EMAIL PROTECTED] wrote: This is now PaceNoFeedState; http://www.intertwingly.net/wiki/pie/PaceNoFeedState +1 e.
Re: Feed State [was: Work Queue Rotation #16]
On 1/2/05 4:18 PM, Mark Nottingham [EMAIL PROTECTED] wrote: P.S. Feed Document may be somewhat misleading, because it's easy to confuse it with Feed (which has connotations of the information channel). I think Feed Snapshot Document or the like was once proposed, but it was shot down. *shrug* Atom Collection Document might be even more accurate, as this also suits temporal period archives or a handpicked set of best essays of 2004. If so, perhaps we could change the top level element name from feed to collection? Do we need a Pace? e.
Re: Feed State [was: Work Queue Rotation #16]
Tuesday, February 1, 2005, 5:18:44 AM, you wrote: P.S. Feed Document may be somewhat misleading, because it's easy to confuse it with Feed (which has connotations of the information channel). I think Feed Snapshot Document or the like was once proposed, but it was shot down. *shrug* In my RDF mapping http://djpowell.net/atomrdf/0.1/ I modelled the thing with the id as a Feed, and used FeedInstance as a term for the version of feed properties that is delivered in the document. Same for Entry and EntryInstance. It is clear that feeds and entries are expected to change so I modelled the different instances as separate entities. This way you can use the same model whether you only care about the latest instance, or if you want to keep historic instances. [*] Anyway - would it be worth using the term Entry Instance in the spec? Would it make ids easier to explain? * You'd annotate each instance with something like atomrdf:receivedDate so that you can select the latest version. It works well from RDF - because you are no longer negating information every time something changes, instead you are just taking a selective view on the most recent version of what is available. -- Dave
Feed State [was: Work Queue Rotation #16]
On Jan 31, 2005, at 11:45 AM, Tim Bray wrote: PaceFeedState: If no further discussion: Like PaceSupersede, this model of publishing does not (so far) enjoy consensus support. Partially pro: 2 Contra: 0 Conclusion: Not enough interest. Close it. If this is the direction we go in on this, that's fine with me, but I think that the spec needs to say *something* about managing feed state, even if it's just this: [[[ x. Managing Feed State Atom Processors MAY keep state (e.g., metadata in atom:head, entries) sourced from Atom Feed Documents and combine them with other Atom Feed Documents, in order to facilitate a contiguous view of the contents of the feed. The manner in which Atom Feed Documents are combined in order to reconstruct a feed (including methods of identifying duplicate entries, updating metadata, and dealing with missing entries) is out of the scope of this specification, but may be defined by an extension to Atom. ]]] So, if we drop PaceFeedState, I propose the text above. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Re: Feed State [was: Work Queue Rotation #16]
At 08:46 05/02/01, Mark Nottingham wrote: [[[ x. Managing Feed State Atom Processors MAY keep state (e.g., metadata in atom:head, entries) sourced from Atom Feed Documents and combine them with other Atom Feed Documents, in order to facilitate a contiguous view of the contents of the feed. The manner in which Atom Feed Documents are combined in order to reconstruct a feed (including methods of identifying duplicate entries, updating metadata, and dealing with missing entries) is out of the scope of this specification, but may be defined by an extension to Atom. ]]] So, if we drop PaceFeedState, I propose the text above. Fine with me, except that I'd change the second parenthesis from: (including methods of identifying duplicate entries, updating metadata, and dealing with missing entries) to: (including methods of updating metadata and dealing with missing entries) How to identify duplicate entries is clear from the description of the id attribute, so I don't think it belongs here. Regards,Martin.
