RE: General/Specific [was: Feed History / Protocol overlap]

> * Reconstructing a feed should use: > a) a specific relation, e.g., "prev-archive" -1 > b) a generic relation, e.g., "previous" +1

Re: General/Specific [was: Feed History / Protocol overlap]

On 10/19/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: > Perhaps people could +1/-1 the following options: > > * Reconstructing a feed should use: > a) a specific relation, e.g., "prev-archive" -1 > b) a generic relation, e.g., "previous" +1 -joe -- Joe Gregoriohttp://bitwo

Re: General/Specific [was: Feed History / Protocol overlap]

Am 19.10.2005 um 19:12 schrieb Mark Nottingham: * Reconstructing a feed should use: a) a specific relation, e.g., "prev-archive" +0 b) a generic relation, e.g., "previous" +1

Re: Feed History / Protocol overlap

>>> Ok, somehow this slipped under the radar on me during >>> my first reading. -1, as I prefer next, as in, the *next* >>> document in a chain of documents. > >> "No matter which direction you head in, no matter which way the chain is >> sorted, the next document is always "next", so that's not

Re: General/Specific [was: Feed History / Protocol overlap]

Thomas Broyer wrote: Mark Nottingham wrote: Perhaps people could +1/-1 the following options: * Reconstructing a feed should use: a) a specific relation, e.g., "prev-archive" -1, (see James' comments) b) a generic relation, e.g., "previous" +1 Hmm, I might have answered a bit too f

Re: General/Specific [was: Feed History / Protocol overlap]

On 20/10/05 3:12 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: > b) a generic relation, e.g., "previous" +1

Re: Feed History / Protocol overlap

Eric Scheid wrote: > On 19/10/05 10:58 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: > > I already have code that uses "next" for this. Why do we want to change it? >>> >>>Why did you choose "next"? >> >>Because that is what's already been deployed and what my software uses. > > > -1. >

Re: General/Specific [was: Feed History / Protocol overlap]

Mark Nottingham wrote: Perhaps people could +1/-1 the following options: * Reconstructing a feed should use: a) a specific relation, e.g., "prev-archive" -1, (see James' comments) b) a generic relation, e.g., "previous" +1 -- Thomas Broyer

Re: General/Specific [was: Feed History / Protocol overlap]

* Reconstructing a feed should use: a) a specific relation, e.g., "prev-archive" +0 b) a generic relation, e.g., "previous" +1

Re: General/Specific [was: Feed History / Protocol overlap]

On Oct 19, 2005, at 11:12 AM, Mark Nottingham wrote: "next" "next-chunk" "next-page" "next-archive" "next-entries" are all workable for me. ... Perhaps people could +1/-1 the following options: * Reconstructing a feed should use: a) a specific relation, e.g., "prev-archive" b) a gene

Re: General/Specific [was: Feed History / Protocol overlap]

Mark Nottingham wrote: Perhaps people could +1/-1 the following options: * Reconstructing a feed should use: a) a specific relation, e.g., "prev-archive" -1. We've got more paging use cases to think about than just archives. OpenSearch already demonstrates that. b) a generic rel

General/Specific [was: Feed History / Protocol overlap]

"next" "next-chunk" "next-page" "next-archive" "next-entries" are all workable for me. I think the real question is still (unfortunately) how specific it should be. I think there are merits to both sides; the relative cost of a specific term isn't much, and the harm of a general term is la

Re: Feed History / Protocol overlap

Antone Roundy wrote: > On Oct 18, 2005, at 5:13 PM, Robert Sayre wrote: >> rel: next >> definition: A URI that points to the next feed in a series of feeds. >> For example, in a reverse-choronological series of feeds, the 'next' >> URI would point deeper into the past. > > Ohh, nice readability.

Re: Feed History / Protocol overlap

Here's what this discussion makes me think of--RSS has a link element. That link was very generic, and has been variously used to link to what Atom calls link/@rel="alternate" and link/ @rel="related", and perhaps even other things. Once we'd gained a little experience and discovered tha

Re: Feed History / Protocol overlap

On 19/10/05 10:58 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >>> I already have code that uses "next" for this. Why do we want to change it? >> >> Why did you choose "next"? > > Because that is what's already been deployed and what my software uses. -1. Someone else made a poor choice*, y

Re: Feed History / Protocol overlap

On Oct 18, 2005, at 6:10 PM, Robert Sayre wrote: On 10/18/05, Antone Roundy <[EMAIL PROTECTED]> wrote: -3 to being that generic. That's a very large negative number. Can you explain how your version will me write software I otherwise couldn't? Anything larger than -2 is bogomips--the point

Re: Feed History / Protocol overlap

On 19/10/05 9:13 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: > rel: next > definition: A URI that points to the next feed in a series of feeds. > For example, in a reverse-choronological series of feeds, the 'next' > URI would point deeper into the past. How will your code cope with a forward-

Re: Feed History / Protocol overlap

On 10/18/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > > On 19/10/05 5:38 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: > > > I already have code that uses "next" for this. Why do we want to change it? > > Why did you choose "next"? Because that is what's already been deployed and what my software

Re: Feed History / Protocol overlap

On 19/10/05 5:38 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: > I already have code that uses "next" for this. Why do we want to change it? Why did you choose "next"? e.

Re: Feed History / Protocol overlap

On 10/18/05, Antone Roundy <[EMAIL PROTECTED]> wrote: > -3 to being that generic. That's a very large negative number. Can you explain how your version will me write software I otherwise couldn't? Robert Sayre

Re: Feed History / Protocol overlap

On Oct 18, 2005, at 5:58 PM, James M Snell wrote: Antone Roundy wrote: On Oct 18, 2005, at 5:13 PM, Robert Sayre wrote: On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: rel: next definition: A URI that points to the next feed in a series of feeds. For example, in a reverse-choronologica

Re: Feed History / Protocol overlap

Antone Roundy wrote: On Oct 18, 2005, at 5:13 PM, Robert Sayre wrote: On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: rel: next definition: A URI that points to the next feed in a series of feeds. For example, in a reverse-choronological series of feeds, the 'next' URI would point de

Re: Feed History / Protocol overlap

On Oct 18, 2005, at 5:13 PM, Robert Sayre wrote: On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: rel: next definition: A URI that points to the next feed in a series of feeds. For example, in a reverse-choronological series of feeds, the 'next' URI would point deeper into the past. Ohh

Re: Feed History / Protocol overlap

On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > 2.) I still don't see how this helps me write a client. > > What are you looking for? People said they wanted to use atom:link, > so I'm trying to accommodate that. People said they wanted the > relations to be generic, so I'm trying to a

Re: Feed History / Protocol overlap

Please disambiguate "original." On 18/10/2005, at 12:49 PM, James M Snell wrote: +1 on all of Roberts comments. While I'm ok with the current version, I was much happier with the original. Robert Sayre wrote: On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: I'm confused; the cu

Re: Feed History / Protocol overlap

On 18/10/2005, at 12:38 PM, Robert Sayre wrote: A stable URI that, when dereferenced, returns a feed document containing a set of entries that sequentially precede those in the current document. I already have code that uses "next" for this. Why do we want to change it? Why would your co

Re: Feed History / Protocol overlap

Robert Sayre wrote: [about the "previous" link relation] A stable URI that, when dereferenced, returns a feed document containing a set of entries that sequentially precede those in the current document. I already have code that uses "next" for this. Why do we want to change it? Er,

Re: Feed History / Protocol overlap

+1 on all of Roberts comments. While I'm ok with the current version, I was much happier with the original. Robert Sayre wrote: On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: I'm confused; the current proposal (below) doesn't have that text in it; for example, the definition o

Re: Feed History / Protocol overlap

On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: > I'm confused; the current proposal (below) doesn't have that text in > it; for example, the definition of previous is: OK, then I am confused. > > > A stable URI that, when dereferenced, returns a feed document > > containing a set of ent

Re: Feed History / Protocol overlap

I'm confused; the current proposal (below) doesn't have that text in it; for example, the definition of previous is: A stable URI that, when dereferenced, returns a feed document containing a set of entries that sequentially precede those in the current document. This can be thought of as

Re: Feed History / Protocol overlap

On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > On 18/10/2005, at 11:38 AM, Robert Sayre wrote: > > >> OK, well, I'm not terribly fussed by who registers them, but they > >> need to be carefully defined, and it wasn't at all clear that the > >> OpenSearch document did that. > >> > > >

Re: Feed History / Protocol overlap

On 18/10/2005, at 11:38 AM, Robert Sayre wrote: OK, well, I'm not terribly fussed by who registers them, but they need to be carefully defined, and it wasn't at all clear that the OpenSearch document did that. I think maybe we have a difference of opinion on what's needed here. Could you

Re: Feed History / Protocol overlap

On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: > OK, well, I'm not terribly fussed by who registers them, but they > need to be carefully defined, and it wasn't at all clear that the > OpenSearch document did that. I think maybe we have a difference of opinion on what's needed here. > C

Re: Feed History / Protocol overlap

OK, well, I'm not terribly fussed by who registers them, but they need to be carefully defined, and it wasn't at all clear that the OpenSearch document did that. Considering that there's a need for them sooner rather than later, would you have a problem with registering the link relations

Re: Feed History / Protocol overlap

On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: > Can you substantiate that with links to the appropriate portions of > the current protocol draft? Oh that's odd. They've gone and deleted them. I can tell you that my general impression of the current atom-protocol list was that we would a

Re: Feed History / Protocol overlap

Can you substantiate that with links to the appropriate portions of the current protocol draft? On 18/10/2005, at 9:40 AM, Robert Sayre wrote: I think the navigation elements of draft-nottingham-atompub-feed-history-04.txt overlap with Atom protocol navigation and deployed APP beta implem

Feed History / Protocol overlap

I think the navigation elements of draft-nottingham-atompub-feed-history-04.txt overlap with Atom protocol navigation and deployed APP beta implementations. In fact, I pointed this out way back in April 2005. I don't think anything has changed. In