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

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

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

2005-10-18 Thread Eric Scheid
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]

2005-10-18 Thread Thomas Broyer
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: 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 t

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: 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,

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

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

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

2005-10-17 Thread James M Snell
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: 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: 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: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-17 Thread Mark Nottingham
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: 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 -- s

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 differen

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 s

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

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

2005-10-17 Thread Mark Nottingham
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: 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 wha

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

2005-10-17 Thread Mark Nottingham
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