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

> 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 > -- s

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

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

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

On 19/10/05 7:06 AM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote: >> The word 'archives' is too general though. May I suggest @rel="history" >> instead? > I'm not a native English speaker soŠ > > Šbut what's wrong with "archives"? IIRC, you wanted a new link relation specific to historical style

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

Eric Scheid wrote: 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 gene

Re: Feed History -04

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 Subject: Re: Feed History -04 Robert Sayre wrote: On 10/17

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

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 t

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

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 a

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

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: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

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,

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

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

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

James M Snell wrote: > > Thomas Broyer wrote: >> Depends whether @rel="self" was really meant for subscribing and the >> spec wording is not precise enough about it; this could then be fixed >> with an errata rather than create a new link relation… >> Otherwise, +0.5, because it seems to overlap

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

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 to a single feed? If a feed

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

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: New Link Relations? [was: Feed History -04]

Mark Nottingham wrote: One other thought; what about "first-entries", "next-entries", "previous-entries", "last-entries"? Blech... -1 Everything else, +1 - James

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

On 17/10/2005, at 5:14 PM, James M Snell wrote: Hmm.. better than before. It would be better if you left it at the "at the time it was minted" part and left out the sentence that follows. But I can live with it. That phrase is probably redundant. Which leaves: - Attribute Value: previ

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

+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 i

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

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 startin

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

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 Fee

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

Antone Roundy wrote: Yeah, but what if you need what amounts to a multi-dimensional array. The method of addressing each dimension has to be distinguishable from the others. Ok, what if? Do you have any specific use cases where this would be required with feed linking? And how theoreti

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

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 exten

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

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- s

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

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 resour

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

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]

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 the

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

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 the set of entries furthest

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

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: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

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]

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]

Oh, no. I'd never sink to *those* depths! On 17/10/2005, at 4:19 PM, James M Snell 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

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

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 precise enough about it; this could then be fixed > with an errata rather than create a new link relationŠ IIRC, it came into existence to

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

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 ord

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

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 -- s

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

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 differen

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

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 s

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

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: New Link Relations? [was: Feed History -04]

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 f

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

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: Feed History -04

Eric Scheid wrote: I've been amusing myself with a thought experiment this morning too. Say I had a set of feed documents, all arranged from "hottest" to "coldest" using @rel='hotter' and @rel='colder'. There are no other links in the feed documents. Say for the sake of argument that the most

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

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

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

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]

I would too, but getting to "the basic function is the same" requires a lot of foresight, if not luck. This isn't directed at anyone in particular, but this discussion has taken shades of the absurd for a while now -- it seems like people are solving theoretical, not actual, problems. I h

Re: Feed History -04

On 18/10/05 7:10 AM, "James Holderness" <[EMAIL PROTECTED]> wrote: > Personally I wouldn't care at all except for one reason. There exists a > published "specification" that defines "next" as pointing to the next most > recent archive, and at least one feed that follows that spec. Whatever is > d

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

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 wha

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

Mark Nottingham wrote: I do believe that a "last" link relation would be helpful for completeness and I do believe the use cases are there (e.g. search results, etc) but I am ok with dropping that for now as it can easily be defined later once the use cases do become more prominent. Over t

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

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. As it is, no one has even noticed it had similarity to this proposal unti

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

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- significance into the feed is going to fail... just

Re: Feed History -04

James M Snell wrote: if I point my newsreader to a feed document that has a incremental=true, I would look for a start link. I would process the start feed then begin walking my way through the next links to build the history. The start feed MAY have the most recent entries or MAY have the

Re: Feed History -04

Eric Scheid wrote: This makes perfect sense if you're a human reading messages, but now try and understand it from the point of view of a computer program (an Atom processor). The computer doesn't care which messages came first. Yes, the _computer_ does *not* care. So why should it's preferen

Re: Feed History -04

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 ni

Re: Feed History -04

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 speci

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

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 diff

Re: Feed History -04

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 de

Re: Feed History -04

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 achieved

Re: Feed History -04

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 b

Re: Feed History -04

Thomas Broyer wrote: This has been debated. There have been those who have expressed an interest in having next and prev links traverse an archive of old non-incremental feeds. Say you have a feed with the top 10 books for this month. The next link (or prev link, depending on your preference)

Re: Feed History -04

Mark, I honestly believe that feed history can be achieved using a very simple model: a. incremental=true... which means that entries (posted at any time) may exist in other feed documents b. start/next/prev... points to other feeds where entries may be found if I point my newsreader to a f

Re: Feed History -04

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

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

Re: Feed History -04

James Holderness wrote: 5. Is the issue of whether a feed is incremental or not (the fh:incremental element) relevant to this proposal? non-incremental feeds wouldn't be paged, by definition, would they? This has been debated. There have been those who have expressed an interest in having

Re: Feed History -04

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

On Oct 17, 2005, at 11:25 AM, Eric Scheid wrote: 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 ti

Re: Feed History -04

On Oct 17, 2005, at 11:06 AM, Byrne Reese wrote: 5. Is the issue of whether a feed is incremental or not (the fh:incremental element) relevant to this proposal? non-incremental feeds wouldn't be paged, by definition, would they? Why not? Why wouldn't I have a "Top 100 DVDs of All Time" bro

Re: Feed History -04

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. Te

Re: Feed History -04

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 y

Re: Feed History -04

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 >> 'fi

RE: Feed History -04

> > 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 article used next. > > I'd prefer that our use of 'prev' and 'next' be consistent > with other uses els

Re: Feed History -04

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 the

Re: Feed History -04

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

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.

Re: Feed History -04

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

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 i

Re: Feed History -04

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 t

RE: Feed History -04

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 entrie

Re: Feed History -04

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 article used next. I'd prefer that our use of

Re: Feed History -04

Here's another thought. Thus far, we've talked about next/previous/first/last links appearing on the atom:feed element... used as a means of linking Atom Feed Documents together. These same link relations could be used on atom:entry as well used as a way of creating a linked list of Ato

Re: Feed History -04

archives/2005/10/15/welcome-to-the-atomowl/ On Sat, 15 Oct 2005, Mark Nottingham wrote: Date: Sat, 15 Oct 2005 20:45:35 -0700 From: Mark Nottingham <[EMAIL PROTECTED]> To: Eric Scheid <[EMAIL PROTECTED]> Cc: Atom Syntax Subject: Re: Feed History -04 OK, but that still leaves us wi

Re: Feed History -04

Henry Story wrote: 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 alpha

Re: Feed History -04

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 autho

Re: Feed History -04

ED]> To: Eric Scheid <[EMAIL PROTECTED]> Cc: Atom Syntax 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:

Re: Feed History -04

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 reas

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 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: Can you walk me through a use cas

Re: Feed History -04

On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: >>> Can you walk me through a use case where this would be desirable? >>> E.g. what would the subscription URI be, would any of the entries >>> be updated, and how if so? In what scenario would having a closed >>> set feed be use

Re: Feed History -04

On 14/10/2005, at 10:24 PM, James M Snell wrote: 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 this would be desirable? E.g. what would the subscription URI be, would any of the entries be up

Re: Feed History -04

Mark Nottingham wrote: 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

Re: Feed History -04

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 wher

Re: Feed History -04

On 15/10/05 1:32 PM, "James M Snell" <[EMAIL PROTECTED]> wrote: > My answer would be: if "last" is used, it's a closed set; if "last" is > not used, it's an open set. +1 ... if it's an open set and you've put 'last' links into every archive, then every time you extend the set you have to rewrite

Re: Feed History -04

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 anc

Re: Feed History -04

Mark Nottingham wrote: 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="su

Re: Feed History -04

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 subscriptio

Re: Feed History -04

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 ge

Re: Feed History -04

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 nee

Re: Feed History -04

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 o

Re: Feed History -04

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

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? Re

Re: Feed History -04

* 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 //

Re: Feed History -04

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 w

Re: Feed History -04

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 wit

Re: Feed History -04

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 sh

Re: Feed History -04

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 seq

RE: Feed History -04

extension comes to mind specifically). I can even see value for a feed to specify more information about its "result set": 10 21 30 55 /feed/entry/published ascending -Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham

  1   2   >