Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread James Snell
> 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 li

Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread Eric Scheid
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.a

Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread Tim Bray
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

Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-02 Thread Robert Sayre
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 s