RE: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-24 Thread Byrne Reese
As I said before, if the WG can reach consensus, I'm happy with any old term. I hadn't seen Mark's proposal till a few days ago, and a mention in an xml.com does not, in my opinion, a spec-in-stone make. My only pushback on next is that to me, it seems counterintuititive -- same as

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-19 Thread Robert Sayre
On 10/17/05, Mark Nottingham [EMAIL PROTECTED] wrote: Robert, It's a matter of personal preference as to whether one likes 'prev' or 'next'; ... My concern is that if there is more than one use of a link relation like 'next' or 'prev', those uses could conflict. ... This is why I'm leaning

Re: New Link Relations? [was: Feed History -04]

2005-10-18 Thread Eric Scheid
On 18/10/05 3:32 PM, Mark Nottingham [EMAIL PROTECTED] wrote: Such agents should also take care to detect circular references between feeds when following them. s/between feeds when/between feed documents/ otherwise +1 e.

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-18 Thread Thomas Broyer
Antone Roundy wrote: If the complete set represents all the entries ever published through an ever-changing feed document (what a feed currently is, you subscribe with an URI and the document you get when dereferencing the URI changes as a sliding-window upon a set of entries), then paging

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-18 Thread Eric Scheid
On 18/10/05 6:14 PM, Thomas Broyer [EMAIL PROTECTED] wrote: Yes, and navigating through the historical states of the feed resource is not paging, it's more like having access to archives. I was thinking about proposing yet another link relation archives: in the general use case, it would

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-18 Thread Eric Scheid
On 18/10/05 5:51 PM, Thomas Broyer [EMAIL PROTECTED] wrote: How can there be more than one paging semantic applied to a single feed? If a feed (not feed document) is a set of entries (sorted by whatever metadata: updated, priority, relevance, etc.) and you publish chunks as many feed

Re: New Link Relations? [was: Feed History -04]

2005-10-18 Thread Robert Sayre
On 10/18/05, Mark Nottingham [EMAIL PROTECTED] wrote: Requiring a separate element to always be present is a non-starter; what is the point of a reusable link relation if you have to use it with another element to contextualise it? I'm really stretching to see any benefit from this approach.

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-18 Thread James M Snell
Thomas Broyer wrote: Mark Nottingham wrote: They seem similar. But, what if you want to have more than one paging semantic applied to a single feed, and those uses of paging don't align? I.e., there's contention for prev/next? How can there be more than one paging semantic applied

Re: Feed History -04

2005-10-18 Thread Henry Story
wrote: Date: Mon, 17 Oct 2005 12:31:38 -0700 From: James M Snell [EMAIL PROTECTED] To: Robert Sayre [EMAIL PROTECTED] Cc: Byrne Reese [EMAIL PROTECTED], Eric Scheid [EMAIL PROTECTED], Atom Syntax atom-syntax@imc.org Subject: Re: Feed History -04 Robert Sayre wrote: On 10/17/05, Byrne

RE: Feed History -04

2005-10-17 Thread Lindsley Brett-ABL001
I would like to toss out another thought - since the updated time of a feed is required, maybe it can be used to help determine the feed order/history. For example, if following a next link (or pick your favorite term), if the updated time gets older, then the client can understand these entries

Re: Feed History -04

2005-10-17 Thread Eric Scheid
On 17/10/05 9:30 PM, Lindsley Brett-ABL001 [EMAIL PROTECTED] wrote: I would like to toss out another thought - since the updated time of a feed is required, maybe it can be used to help determine the feed order/history. For example, if following a next link (or pick your favorite term), if

Re: Feed History -04

2005-10-17 Thread James Holderness
Eric Scheid wrote: I'd prefer that our use of 'prev' and 'next' be consistent with other uses elsewhere, where 'next' traverses from the current position to the one that *follows*, whether in time or logical order. Consider the use of 'first/next/prev/last' with chapters or sections rendered

Re: Feed History -04

2005-10-17 Thread Mark Nottingham
On 17/10/2005, at 1:20 AM, Eric Scheid wrote: I'd prefer that our use of 'prev' and 'next' be consistent with other uses elsewhere, where 'next' traverses from the current position to the one that *follows*, whether in time or logical order. Consider the use of 'first/next/prev/last' with

Re: Feed History -04

2005-10-17 Thread Eric Scheid
On 18/10/05 12:43 AM, James Holderness [EMAIL PROTECTED] wrote: Eric Scheid wrote: I'd prefer that our use of 'prev' and 'next' be consistent with other uses elsewhere, where 'next' traverses from the current position to the one that *follows*, whether in time or logical order. Consider

Re: Feed History -04

2005-10-17 Thread Antone Roundy
On Oct 17, 2005, at 2:20 AM, Eric Scheid wrote: On 17/10/05 5:09 PM, James Holderness [EMAIL PROTECTED] wrote: 1. Which relationship, next or prev, is used to specify a link backwards in time to an older archive. Mark Nottingham's Feed History proposal used prev. Mark Pilgrim's XML.com

Re: Feed History -04

2005-10-17 Thread Antone Roundy
On Oct 17, 2005, at 10:04 AM, Antone Roundy wrote: 4. Is the order of the entries in a feed relevant to this proposal? ... 1) A chain of temporally ordered chunks in the history of a feed where new entries are tacked onto the end. 2) Search results, where the order of everything all along

Re: Feed History -04

2005-10-17 Thread Eric Scheid
On 18/10/05 2:04 AM, Antone Roundy [EMAIL PROTECTED] wrote: I'd prefer that our use of 'prev' and 'next' be consistent with other uses elsewhere, where 'next' traverses from the current position to the one that *follows*, whether in time or logical order. Consider the use of

Re: Feed History -04

2005-10-17 Thread Eric Scheid
On 18/10/05 2:04 AM, Antone Roundy [EMAIL PROTECTED] wrote: Can self be polymorphic--the subscription URI in the live end of a feed, and this chunk in a historical chunk? Can an extension speak authoritatively about the meaning of something from the core spec? If it were so, and you were

Re: Feed History -04

2005-10-17 Thread Eric Scheid
On 18/10/05 2:04 AM, Antone Roundy [EMAIL PROTECTED] wrote: 2) Search results, where the order of everything all along the entire chain shifts around all the time. BTW, case 2 destroys the idea of a fixed end and a live end. Case 2 would be a closed set, generally speaking. geeking

Re: Feed History -04

2005-10-17 Thread James Holderness
Eric Scheid wrote: Ask yourself these questions: which is the first message in this thread, and if you wanted to understand the thread would you start there, or at the most recent entry in this thread and read backwards. Remember that by the time you've read back to the initial posting there

Re: Feed History -04

2005-10-17 Thread Robert Sayre
On 10/17/05, Byrne Reese [EMAIL PROTECTED] wrote: next and previous are as James points out, orthogonal to ordering. The debate as to whether the next set goes backwards or forwards in time is not about the use of the terms next and previous, it is about the default sort order of a result

Re: Feed History -04

2005-10-17 Thread Mark Nottingham
Exactly. I don't want this draft to become the all-singing, all-dancing feed model review; although there's lots of interesting stuff there, it's way too ambitious for my tastes (and I think I detect the smell of a tarpit faintly wafting...). The feed history case gets us to a nice 80 +%

Re: Feed History -04

2005-10-17 Thread Eric Scheid
On 18/10/05 4:39 AM, James Holderness [EMAIL PROTECTED] wrote: Eric Scheid wrote: Ask yourself these questions: which is the first message in this thread, and if you wanted to understand the thread would you start there, or at the most recent entry in this thread and read backwards.

Re: Feed History -04

2005-10-17 Thread Mark Nottingham
I already get the same results with just one link relation -- 'prev- archive' -- instead of three. The algorithm for combining results is an important issue, but an orthogonal one. On 17/10/2005, at 12:37 PM, James M Snell wrote: Mark, I honestly believe that feed history can be

Re: Feed History -04

2005-10-17 Thread James M Snell
Robert Sayre wrote: On 10/17/05, Byrne Reese [EMAIL PROTECTED] wrote: next and previous are as James points out, orthogonal to ordering. The debate as to whether the next set goes backwards or forwards in time is not about the use of the terms next and previous, it is about the default

Re: Feed History -04 -- is it history or paging or both?

2005-10-17 Thread Antone Roundy
If we're going to separate the concepts of history and paging, then the term history doesn't really apply to incremental feeds. In an incremental feed, all of the entries are part of the current state of the feed. We don't go back through history to find the present--we go to different

Re: Feed History -04

2005-10-17 Thread Robert Sayre
On 10/17/05, Mark Nottingham [EMAIL PROTECTED] wrote: I already get the same results with just one link relation -- 'prev- archive' -- instead of three. Why should one prefer your proposal to what's in this feed: http://diveintomark.org/xml/2004/03/index.atom 'prev-archive' is more specific,

Re: Feed History -04

2005-10-17 Thread Thomas Broyer
Mark Nottingham wrote: I don't want this draft to become the all-singing, all-dancing feed model review; although there's lots of interesting stuff there, it's way too ambitious for my tastes (and I think I detect the smell of a tarpit faintly wafting...). The feed history case gets us to a

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-17 Thread James M Snell
I know this was directed to Robert, but I'd like to throw my $.02 in. Generally speaking, if the semantic difference between the use of next/prev in one feed relative to another can be expressed using a separate extension (e.g. the presence of an incremental=true or a profile attribute or

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Mark Nottingham
Good point. On 17/10/2005, at 2:54 PM, James M Snell wrote: +1. An additional security concern would be the potential for circular references -- Mark Nottingham http://www.mnot.net/

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-17 Thread Robert Sayre
On 10/17/05, Mark Nottingham [EMAIL PROTECTED] wrote: Robert, It's a matter of personal preference as to whether one likes 'prev' or 'next'; if there had been wide implementation and a good specification of what MarkP did, I could see a strong argument for using it. I think the spec is

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Thomas Broyer
Mark Nottingham wrote: - Attribute Value: prev - Description: A stable URI that, when dereferenced, returns a feed document containing entries that sequentially precede those in the current document. Note that the exact nature of the ordering between the entries and documents containing them

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread James M Snell
Thomas Broyer wrote: - Attribute Value: subscribe - Description: A stable URI that, when dereferenced, returns a feed document containing the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of changes in the feed. When different from the URI of the

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-17 Thread Mark Nottingham
They seem similar. But, what if you want to have more than one paging semantic applied to a single feed, and those uses of paging don't align? I.e., there's contention for prev/next? If no one shares my concern, I'll drop it... as long as I get to say I told you so if/when this problem

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-17 Thread James M Snell
Mark Nottingham wrote: They seem similar. But, what if you want to have more than one paging semantic applied to a single feed, and those uses of paging don't align? I.e., there's contention for prev/next? If no one shares my concern, I'll drop it... as long as I get to say I told you

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-17 Thread Thomas Broyer
Mark Nottingham wrote: My concern is that if there is more than one use of a link relation like 'next' or 'prev', those uses could conflict. For example, if I use 'prev' for Feed History, will that cause a problem with feeds using Amazon OpenSearch if they want to use it in a slightly

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-17 Thread Mark Nottingham
Robert, As I said before, if the WG can reach consensus, I'm happy with any old term. I hadn't seen Mark's proposal till a few days ago, and a mention in an xml.com does not, in my opinion, a spec-in-stone make. My only pushback on next is that to me, it seems counterintuititive --

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Mark Nottingham
On 17/10/2005, at 4:07 PM, Thomas Broyer wrote: - Attribute Value: first - Description: A stable URI that, when dereferenced, returns a feed document containing those entries furthest preceding those in the current document at the time it was minted. Note that the exact nature of the

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread James M Snell
Mark Nottingham wrote: A stable URI was intended to capture that, but I see that wasn't good enough. How about: - Attribute Value: first - Description: A stable URI that, when dereferenced, returns a feed document containing the set of entries furthest preceding those in the current

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-17 Thread Robert Sayre
On 10/17/05, Mark Nottingham [EMAIL PROTECTED] wrote: The SixApart people have publicly pointed to FH, Cool! so I don't think they're particularly fussed about any particular approach other (not to put words in their mouth). Did you miss Byrne's post?

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Mark Nottingham
So what happens when you need the rel=self (as currently defined) of an archive feed? On 17/10/2005, at 4:28 PM, Eric Scheid wrote: On 18/10/05 9:07 AM, Thomas Broyer [EMAIL PROTECTED] wrote: Depends whether @rel=self was really meant for subscribing and the spec wording is not

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread James M Snell
Mark Nottingham wrote: The intent here was to say that the *set* of entries is generally stable, not that they're set in stone. That's what you want, no? If so, how about: - Attribute Value: first - Description: A stable URI that, when dereferenced, returns a feed document containing

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-17 Thread Antone Roundy
On Oct 17, 2005, at 5:17 PM, Mark Nottingham wrote: They seem similar. But, what if you want to have more than one paging semantic applied to a single feed, and those uses of paging don't align? I.e., there's contention for prev/next? If no one shares my concern, I'll drop it... as long as

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Eric Scheid
On 18/10/05 9:53 AM, Mark Nottingham [EMAIL PROTECTED] wrote: So what happens when you need the rel=self (as currently defined) of an archive feed? The current definition being ... The value self signifies that the IRI in the value of the href attribute identifies a resource

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Antone Roundy
On Oct 17, 2005, at 3:44 PM, Mark Nottingham wrote: On 17/10/2005, at 12:31 PM, James M Snell wrote: Debating how the entries are organized is fruitless. The Atom spec already states that the order of elements in the feed has no significance; trying to get an extension to retrofit order-

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread James M Snell
Antone Roundy wrote: On Oct 17, 2005, at 3:44 PM, Mark Nottingham wrote: On 17/10/2005, at 12:31 PM, James M Snell wrote: Debating how the entries are organized is fruitless. The Atom spec already states that the order of elements in the feed has no significance; trying to get an

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Antone Roundy
On Oct 17, 2005, at 10:17 PM, James M Snell wrote: When I think of next/prev I'm not thinking about any form of temporal semantic. I'm thinking about nothing more than a linked list of feed documents. If you want to add a temporal semantic into the picture, use a mechanism such as the

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Mark Nottingham
Requiring a separate element to always be present is a non-starter; what is the point of a reusable link relation if you have to use it with another element to contextualise it? I'm really stretching to see any benefit from this approach. prev-archive (or maybe prev-entries?) is starting

Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Mark Nottingham
+1 On 17/10/2005, at 7:57 PM, Eric Scheid wrote: On 18/10/05 9:53 AM, Mark Nottingham [EMAIL PROTECTED] wrote: So what happens when you need the rel=self (as currently defined) of an archive feed? The current definition being ... The value self signifies that the IRI in the

Re: Feed History -04

2005-10-16 Thread Henry Story
Scheid [EMAIL PROTECTED] Cc: Atom Syntax atom-syntax@imc.org Subject: Re: Feed History -04 OK, but that still leaves us with the question below -- who's doing the paging, and why is it useful to have multiple ways around the thing? On 15/10/2005, at 7:25 PM, Eric Scheid wrote: On 16/10/05 6:54

Re: Feed History -04

2005-10-16 Thread Henry Story
I am ok with next, prev, ... but I suppose I do have a question that is similar to Marks: how do I know in what order the results are listed? Are they in historical order? Are these feeds grouping entries in alphabetical order, in inverse historical order? Perhaps in alphabetical order of

Re: Feed History -04

2005-10-16 Thread James M Snell
: Mark Nottingham [EMAIL PROTECTED] To: Eric Scheid [EMAIL PROTECTED] Cc: Atom Syntax atom-syntax@imc.org Subject: Re: Feed History -04 OK, but that still leaves us with the question below -- who's doing the paging, and why is it useful to have multiple ways around the thing? On 15/10/2005

Re: Feed History -04

2005-10-15 Thread Mark Nottingham
OK, but that still leaves us with the question below -- who's doing the paging, and why is it useful to have multiple ways around the thing? On 15/10/2005, at 7:25 PM, Eric Scheid wrote: On 16/10/05 6:54 AM, Mark Nottingham [EMAIL PROTECTED] wrote: Can you walk me through a use case

Re: Feed History -04

2005-10-15 Thread Robert Sayre
On 10/15/05, Mark Nottingham [EMAIL PROTECTED] wrote: OK, but that still leaves us with the question below -- who's doing the paging, and why is it useful to have multiple ways around the thing? James is 100% wrong :)... about last/first/top/head/bottom/hole-in-the-ground. There's no reason

Re: Feed History -04

2005-10-14 Thread Mark Nottingham
The approach I took in -04 was to say that the pseudo-ordering introduced by the mechanism was ONLY meaningful for the purposes of reconstituting the feed; it's still up to the feed itself to determine what the ordering of entries means (or doesn't). That avoids a lot of problems,

Re: Feed History -04

2005-10-14 Thread A. Pagaltzis
* Eric Scheid [EMAIL PROTECTED] [2005-10-14 17:35]: Why would anyone want to know the 'last' link? One use case is that one could take note of the 'last' URI, and then later find out what the 'last' URI now is ... and if they are different then obviously more has been added and it's time to

Re: Feed History -04

2005-10-14 Thread Thomas Broyer
Lindsley Brett-ABL001 wrote: I have a suggestion that may work. The issue of defining what is prev and next with respect to a time ordered sequence seems to be a problem. How about defining the link relationships in terms of time - such as newer and older or something like that. That way, the

Re: Feed History -04

2005-10-14 Thread Mark Nottingham
On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote: I have a suggestion that may work. The issue of defining what is prev and next with respect to a time ordered sequence seems to be a problem. How about defining the link relationships in terms of time - such as newer and older or

Re: Feed History -04

2005-10-14 Thread Thomas Broyer
Mark Nottingham wrote: How about: atom:link rel=subscription href=.../ ? I always thought this was the role of @rel=self to give the URI you should subscribe to, though re-reading the -11 it deals with a resource equivalent to the containing element. 1. Isn't a resource equivalent to the

Re: Feed History -04

2005-10-14 Thread Mark Nottingham
That's what I thought too, but the words in the spec don't bear it out; a resource equivalent to the containing element is a little hard to interpret (there is no equivalence function for Web resources, by definition), but it's a lot closer to something you dereference to get the same

Re: Feed History -04

2005-10-14 Thread Antone Roundy
On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote: On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote: I have a suggestion that may work. The issue of defining what is prev and next with respect to a time ordered sequence seems to be a problem. How about defining the link

Re: Feed History -04

2005-10-14 Thread Antone Roundy
On Oct 14, 2005, at 11:28 AM, Thomas Broyer wrote: Mark Nottingham wrote: How about: atom:link rel=subscription href=.../ ? I always thought this was the role of @rel=self to give the URI you should subscribe to, though re-reading the -11 it deals with a resource equivalent to the

Re: Feed History -04

2005-10-14 Thread James Holderness
Mark Nottingham wrote: I agree that it's important to honour the document order; that's what FH tries to do. I'm a little surprised to hear you say that people thought that this was previously 'next'; I'd never heard that (but will be happy to put a note in). Mark Pilgrim's article on

Re: Feed History -04

2005-10-14 Thread Mark Nottingham
At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't

Re: Feed History -04

2005-10-14 Thread Stefan Eissing
Am 14.10.2005 um 20:00 schrieb James Holderness: Mark Nottingham wrote: Hmm. Yeah, I see what you're saying. Actually, I think this is an opportunity -- we we define a new link relation to the subscription document, and specify that it can only occur in archive documents, it obviates the

RE: Feed History -04

2005-10-14 Thread Byrne Reese
: Friday, October 14, 2005 11:28 AM To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: Feed History -04 At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining

RE: Feed History -04

2005-10-14 Thread Byrne Reese
Subject: Re: Feed History -04 At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after

Re: Feed History -04

2005-10-14 Thread Joe Gregorio
On 10/14/05, Antone Roundy [EMAIL PROTECTED] wrote: On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote: On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote: I have a suggestion that may work. The issue of defining what is prev and next with respect to a time ordered sequence seems to

Re: Feed History -04

2005-10-14 Thread James M Snell
The way I look at this is in terms of a single linked list of feeds. The ordering of the entries within those feeds is irrelevant. The individual linked feeds MAY be incremental (e.g. blog entries,etc) or may be complete (e.g. lists,etc). Simply because a feeds are linked, no assumption

Re: Feed History -04

2005-10-14 Thread Henry Story
This looks good. Is the 'first' the feed document that changes, whereas 'next' and 'last' point to the archives? (in a feed history context?) Henry On Fri, 14 Oct 2005, James M Snell wrote: The way I look at this is in terms of a single linked list of feeds. The ordering of the entries

Re: Feed History -04

2005-10-14 Thread Robert Sayre
On 10/14/05, James M Snell [EMAIL PROTECTED] wrote: The way I look at this is in terms of a single linked list of feeds. James is 100% right. Think of any feed as a google search result, ordered in terms of relevance. On your average blog, the newest post is always the most relevant :). I

Re: Feed History -04

2005-10-14 Thread A. Pagaltzis
* James M Snell [EMAIL PROTECTED] [2005-10-15 00:25]: Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. head/tail? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed History -04

2005-10-14 Thread James M Snell
What in the world is wrong with first and last? ;-) I just don't get it. A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2005-10-15 00:25]: Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. head/tail? Regards,

Re: Feed History -04

2005-10-14 Thread Mark Nottingham
Right. A few questions that pop up: 1) Is it a closed or open set? If it's open (and I think 99% of feeds are), what does last mean? My answer is that it's probably an open set, so last doesn't mean much that's useful (unless it's conflated with the subscription feed; see below). 2)

Re: Feed History -04

2005-10-14 Thread Mark Nottingham
This leads to: Subscription feed: - can contain link/@rel=prev, OR - can contain fh:incremental = false Archive feed: - can contain link/@rel=prev and/or link/@rel=next - can contain link/@rel=subscribe (effectively gives you last) - link/@rel=subscribe has a semantic of if you want

Re: Feed History -04

2005-10-14 Thread James Holderness
Subscription feed: - can contain link/@rel=prev, OR - can contain fh:incremental = false I never did understand this. Why is fh:incremental needed here? From a feed history point of view you either have a history (a prev link is present) or you don't. That's all an Atom processor needs

Re: Feed History -04

2005-10-14 Thread Mark Nottingham
On 14/10/2005, at 8:01 PM, James Holderness wrote: I never did understand this. Why is fh:incremental needed here? From a feed history point of view you either have a history (a prev link is present) or you don't. That's all an Atom processor needs in order to reconstruct the feed. I

Re: Feed History -04

2005-10-14 Thread James M Snell
Mark Nottingham wrote: Right. A few questions that pop up: 1) Is it a closed or open set? If it's open (and I think 99% of feeds are), what does last mean? My answer is that it's probably an open set, so last doesn't mean much that's useful (unless it's conflated with the subscription

Re: Feed History -04

2005-10-14 Thread Eric Scheid
On 15/10/05 8:28 AM, Henry Story [EMAIL PROTECTED] wrote: Is the 'first' the feed document that changes, whereas 'next' and 'last' point to the archives? (in a feed history context?) My thinking is that of the two ends, 'first' and 'last', it would normally be the 'first' end that is

Re: Feed History -04

2005-10-14 Thread Mark Nottingham
On 14/10/2005, at 8:32 PM, James M Snell wrote: 1) Is it a closed or open set? If it's open (and I think 99% of feeds are), what does last mean? My answer would be: if last is used, it's a closed set; if last is not used, it's an open set. Can you walk me through a use case where

RE: Feed History -04

2005-10-13 Thread Byrne Reese
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell Sent: Sunday, October 09, 2005 9:06 PM To: James Holderness Cc: Syntax Atom Subject: Re: Feed History -04 I've been considering asking the Opensearch folks if they would be willing to separate their next/previous/first/last link

Re: Feed History -04

2005-10-13 Thread Joe Gregorio
On 10/10/05, James M Snell [EMAIL PROTECTED] wrote: I've been considering asking the Opensearch folks if they would be willing to separate their next/previous/first/last link relations out to a separate spec that could be made a working group draft. The paging functionality they offer

RE: Feed History -04

2005-10-13 Thread Byrne Reese
+1 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell Sent: Sunday, October 09, 2005 9:06 PM To: James Holderness Cc: Syntax Atom Subject: Re: Feed History -04 I've been considering asking the Opensearch folks if they would be willing

Re: Feed History -04

2005-10-13 Thread Mark Nottingham
I've been considering moving feed history over to atom:link, but wanted to check with people who are currently using / referring to it, as well as with the RSS communities. Please give me a little time. On 09/10/2005, at 9:06 PM, James M Snell wrote: I've been considering asking the

Re: Feed History -04

2005-10-13 Thread James M Snell
Excellent. If this works out, there is an opportunity to merge the paging behavior of Feed History, OpenSearch and APP collections into a single set of paging link relations (next/previous/first/last). Mark Nottingham wrote: I've been considering moving feed history over to atom:link, but

Re: Feed History -04

2005-10-13 Thread Eric Scheid
On 14/10/05 9:18 AM, James M Snell [EMAIL PROTECTED] wrote: Excellent. If this works out, there is an opportunity to merge the paging behavior of Feed History, OpenSearch and APP collections into a single set of paging link relations (next/previous/first/last). 'first' or 'start'? Do we

Re: Feed History -04

2005-10-13 Thread Antone Roundy
On Oct 13, 2005, at 7:58 PM, Eric Scheid wrote: On 14/10/05 9:18 AM, James M Snell [EMAIL PROTECTED] wrote: Excellent. If this works out, there is an opportunity to merge the paging behavior of Feed History, OpenSearch and APP collections into a single set of paging link relations

Re: Feed History -04

2005-10-13 Thread A. Pagaltzis
* Antone Roundy [EMAIL PROTECTED] [2005-10-14 05:10]: On Oct 13, 2005, at 7:58 PM, Eric Scheid wrote: Do we need to define what 'first' means though? I recall a dissenting opinion on the wiki that the 'first' entry could be at either end of the list, which could surprise some. Yeah,

Re: Feed History -04

2005-10-13 Thread Joe Gregorio
On 10/13/05, Eric Scheid [EMAIL PROTECTED] wrote: On 14/10/05 9:18 AM, James M Snell [EMAIL PROTECTED] wrote: Excellent. If this works out, there is an opportunity to merge the paging behavior of Feed History, OpenSearch and APP collections into a single set of paging link relations

Re: Feed History -04

2005-10-13 Thread Eric Scheid
On 14/10/05 2:01 PM, Joe Gregorio [EMAIL PROTECTED] wrote: Eric, It's like deja-vu all over again. http://bitworking.org/news/Atom_Auto_Sub_How_To :) I'd forgotten about that, I was only remembering the wiki. I still think it odd that one could traverse both prev and next from the

Re: Feed History -04

2005-10-09 Thread Henry Story
It occurred to me that I should think a little more before speaking. There seems to be a history of the atom spec here: http://bitworking.org/projects/atom/ I could not find the prev link in any of the specs. So I guess I was mistaken. But I also always thought of prev and next as being

Re: Feed History -04

2005-10-09 Thread James Holderness
Funny you should say that. When you told me it was part of Atom 0.3 I also thought to myself that I should have checked that before posting. Technically you were correct. Version 0.3 of the syndication format doesn't mention next and prev explicitly, but it does say (in section 3.4.1) that

Re: Feed History -04

2005-10-09 Thread Mark Nottingham
Managing Feed State was a placeholder I put in the original Atom spec draft http://www.mnot.net/drafts/draft-nottingham-atom- format-00.html#rfc.section.4 for just this kind of discussion. The WG couldn't come to a consensus on a mechanism (my proposal was

Re: Feed History -04

2005-10-09 Thread Joe Gregorio
. It's in there: http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.5.4.1 So -1 to draft-nottingham-atompub-feed-history-04.txt for not using a link tag of rel=prev. -joe -- Joe Gregoriohttp://bitworking.org

Re: Feed History -04

2005-10-09 Thread Robert Sayre
On 10/9/05, Mark Nottingham [EMAIL PROTECTED] wrote: The format doesn't reference the API document any more, That's good. and the current API document http://www.ietf.org/internet-drafts/draft-ietf- atompub-protocol-04.txt doesn't include anything about that link relation; it was removed.

Re: Feed History -04

2005-10-09 Thread James Holderness
In case anyone is interested, the OpenSearch Response draft can be found here: http://opensearch.a9.com/spec/opensearchresponse/1.1/ The rel values they support include next, previous (not prev), start and end. They have a note next to each saying This value is pending IETF registration.

Re: Feed History -04

2005-10-09 Thread Mark Nottingham
Looks like the whole use URIs for non-registered values approach has already gone by the wayside. Oh, well. Next time, it should just be URIs, period -- no shortcuts. On 09/10/2005, at 3:41 PM, James Holderness wrote: They have a note next to each saying This value is pending IETF

Re: Feed History -04

2005-10-09 Thread James M Snell
I don't think not using the URI is a problem so long as the intent is to register the value and you make an attempt at standardization. The problems arise when folks use names when they have no intention of standardizing or registering. - James Mark Nottingham wrote: Looks like the

Re: Feed History -04

2005-10-09 Thread James M Snell
I've been considering asking the Opensearch folks if they would be willing to separate their next/previous/first/last link relations out to a separate spec that could be made a working group draft. The paging functionality they offer provides a solution to paging in the protocol and are

Re: Feed History -04

2005-10-03 Thread Ian Davis
On 01/10/2005 01:05, James Holderness wrote: Mark Nottingham wrote: Thanks for the feedback. As I've explained before, I have a pretty strong preference for the current design, to make it usable in other formats; i.e., the scope of this is not just Atom (which is why I'm probably going

  1   2   >