Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)
> Potential solutions that occur to me: > > 1. Ignore the problem > 2. PaceEntriesElement could handle this > 3. PaceFeedRecursive could handle this > 4. PaceAtomHeadInEntry could handle this > 5. PaceAggregationDocument could handle this > > I honestly can't say which I prefer. Would anyone like to try to put > together examples of the solution in #2 through #5 so that we can > consider the alternatives? > 6. Handle the problem in a non-core extension. The core Atom syntax does not have to deal with all these cases as long as it does not interfere with someones ability to deal with cases later on. Get version one out the door. Get folks to start implementing it. Start writing up extensions. Get folks to implement those extensions. Figure out which extensions are Really Useful. Add those Really Useful Extensions to the core later. -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)
On 4/2/05 1:15 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: >> 3.) A "List Status" feed, where the only updates consist of one >> collection replacing another. >> >> RSS2 -- >> http://rss.netflix.com/Top100RSS >> >> background info-- >> http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd >> -4cba-959a-2bba6ae917f0 > > Q: Has any previous flavor of RSS had a solution for this? > Q: Do we have a proposal for something to handle this? > > Dare points out that the feed suffers from lack of guids and dates, > something that Atom would force them to fix, which would give an > aggregator a better chance of doing something useful. -Tim This is not too much unlike how Nature Publishing Group is providing RSS1.0 feeds of table of contents for each issue of their journals. They have one feed URI for each issue, and a 304 redirect on the "current issue" feed URI. Each article has a unique id. They also have an RSS feed where each item is a link to each of their various journal titles. They could also quite reasonably have a per-title feed where each item is a link to each issue's feed. e.
Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)
On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote: 1.) A web forum, where one post serves as the root of a collection of other posts. HTML-- http://groups-beta.google.com/group/bloggerDev/ Atom 0.3, "root" posts only-- http://groups-beta.google.com/group/bloggerDev/feed/topics.xml Atom 0.3, all messages-- http://groups-beta.google.com/group/bloggerDev/feed/msgs.xml Q: Has any previous flavor of RSS had a solution for this? Potential solutions that occur to me: 1. Ignore the problem 2. PaceEntriesElement could handle this 3. PaceFeedRecursive could handle this 4. PaceAtomHeadInEntry could handle this 5. PaceAggregationDocument could handle this I honestly can't say which I prefer. Would anyone like to try to put together examples of the solution in #2 through #5 so that we can consider the alternatives? 2.) A Blog w/ comments, where on post serves as the root of a collection of other posts. HTML-- http://www.livejournal.com/users/giant_moose/ Atom 0.3, no indication of comments-- http://www.livejournal.com/users/giant_moose/data/atom Q: Has any previous flavor of RSS had a solution for this? Q: Do we have a proposal on something to handle this? I believe there is a proposal for a which would do the job. 3.) A "List Status" feed, where the only updates consist of one collection replacing another. RSS2 -- http://rss.netflix.com/Top100RSS background info-- http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd -4cba-959a-2bba6ae917f0 Q: Has any previous flavor of RSS had a solution for this? Q: Do we have a proposal for something to handle this? Dare points out that the feed suffers from lack of guids and dates, something that Atom would force them to fix, which would give an aggregator a better chance of doing something useful. -Tim
Organization Use Cases (was: Re: Format spec vs Protocol spec)
Robert Sayre wrote: The problems facing a server storing blog entries are not much different (whether or not the entries are exposed to APP). Our secretary has listed the following paces as "organization" paces, meaning they don't change the definition of many core elements other than the ones serving as "containers". * PaceAggregationDocument * PaceFeedRecursive 1.) A web forum, where one post serves as the root of a collection of other posts. HTML-- http://groups-beta.google.com/group/bloggerDev/ Atom 0.3, "root" posts only-- http://groups-beta.google.com/group/bloggerDev/feed/topics.xml Atom 0.3, all messages-- http://groups-beta.google.com/group/bloggerDev/feed/msgs.xml 2.) A Blog w/ comments, where on post serves as the root of a collection of other posts. HTML-- http://www.livejournal.com/users/giant_moose/ Atom 0.3, no indication of comments-- http://www.livejournal.com/users/giant_moose/data/atom 3.) A "List Status" feed, where the only updates consist of one collection replacing another. RSS2 -- http://rss.netflix.com/Top100RSS background info-- http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd-4cba-959a-2bba6ae917f0 Robert Sayre
