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 -- same as your pushback on prev. *shrug* The SixApart people have publicly pointed to FH, so I don't think they're particularly fussed about any particular approach other (not to put words in their mouth). I wasn't able to find a TP feed that uses rel=next; do you have a link to one? I have been holding back until I found the right message to reply to. I think I found it. As it turns out Six Apart's Japanese office recently released something we call TypePad Mobile and TypeCast. Both products are geared at the same problem: making blogs accessible to mobile devices. TypeCast is about making an Atom powered blogging application, whereas TypePad Mobile's purpose is to make all published blogs completely accessible via Atom. It may be the most comprehensive Atom implementation of its kind, but that is a bold statement to make. (FYI: Tatsuhiko Miyagawa was the lead engineer behind the project.) In TypePad Mobile, Tatsuhiko implemented a rel=next and rel=prev in order to facilitate the following problem: * in browsing a blog on a phone, one can only realistically afford to read 1-3 entries at a time. The implementation addresses the need to: ** veiwing the first n posts on the front door, and then paging through entries that go back in time ** viewing category archives (1 or 2 entries at a time) ** viewing daily/weekly/monthly/yearly archives (1 or 2 entries at a time) ** eventually to view tag archives, most popular archives, etc * next and prev were also used both in the context of the application: ** show me a list of entries I can edit ** show me a list of the most recent comments ** etc. So there is a real live use case. As for me, I am rarely one to get myself involved in a namenclature debate. More often than not, IMHO, they just go in cicles. Plus once you get involved, it is hard to extricate yourself from the debate. So for *me*, I don't really care what the link relations are labeled provided that their usage is well defined, and that there is concenseus around their intended usage. I have come around to favor: next|prev|first|last|(current or subscribe) because it is similar to (if not identical with) what we have alread implemented in our APP implementatin and in Japan. But also it is sufficiently specific and sufficiently open ended to give me (the implementer) a very reasonable set of ways to apply the principal. Byrne Reese
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 leaning towards prev-archive. OK. 'prev-archive' is fine. Let's throw it against the wall see if it sticks. No amount of atom-syntax traffic is going to resolve this. We'll see if it turns out to be useful. Robert Sayre
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: 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), then paging allows for feed state reconstruction. In other terms, feed state reconstruction is a facet of paging, an application to non-incremental feeds. Let's say you're doing a feed for the Billboard top 100 songs. Each week, the entire contents of the feed are swapped out and replaced by a new top 100 (ie. it is a non-incremental feed). And let's say you don't want to put all 100 in the same document, but you want to break it up into 4 documents with 25 entries each. You now have two potential axes that people might want to traverse--from songs 1-25 to 26-50 to 51-75 to 76-100, or from this weeks 1-25 to last weeks 1-25 to two weeks ago's 1-25, etc. You can't link in both directions with the same next. There are clearly two distinct concepts here--navigating through the chunks that make up the current state of the feed resource, and in a non-incremental feed, navigating though the historical states of the feed resource. 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 reference another feed document where each entry describes an archive: Top 100 feed: feed xmlns... titleOctober 2005 Top 100/title fh:incremental xmlns...no/fh:incremental !-- this links to the next chunk of the non-incremental feed -- link rel=next type=application/atom+xml href=26-50.atom title=26 to 50 entries / !-- this links to a list of archives -- link rel=archives type=application/atom+xml href=../archives.atom title=Top 100 archives / ... Archive feed: feed xmlns... fh:incremental xmlns...yes/fh:incremental !-- this links to the next chunk of the archive feed -- link rel=next type=application/atom+xml href=archives2.atom / ... entry titleSeptember 2005 Top 100/title content type=application/atom+xml src=2005/09/1-25.atom / ... /entry entry titleAugust 2005 Top 100/title content type=application/atom+xml src=2005/08/1-25.atom / ... /entry ... September 2005 Top 100 feed: feed xmlns... titleSeptember 2005 Top 100/title fh:incremental xmlns...no/fh:incremental !-- this links to the next chunk of the non-incremental feed -- link rel=next type=application/atom+xml href=26-50.atom title=26 to 50 entries / !-- this links to a list of archives -- link rel=archives type=application/atom+xml href=../archives.atom title=Top 100 archives / ... -- Thomas Broyer
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, it would reference another feed document where each entry describes an archive: The word 'archives' is too general though. May I suggest @rel=history instead? Otherwise, +1 e.
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 documents, paging is navigation from one to the other, following the sort order. ... and the subset of entries which are on page 1 sorted by one axis would be very unlikely to be on page 1 when sorted by some other axis. d'oh! If you want to provide the exact same entries sorted (thus paged) differently, then that's another feed. unless of course each feed document contains only one entry each ;-) e.
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 approach. prev-archive (or maybe prev-entries?) is starting to look better, as is fh:prev/. Hogwash. Do not reinvent the AtomAPI. Posting on atom-syntax and then claiming your way is the right way after all because people are arguing and some folks are saying silly things... why did you bother? Robert Sayre
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 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 documents, paging is navigation from one to the other, following the sort order. If you want to provide the exact same entries sorted (thus paged) differently, then that's another feed. +1
Re: Feed History -04
My laptop broke down so I am having touble following all of this thread, but I agree that next, prev, ... should just suggest a linked list. There should then be special links for hist-prev, hist-next, ... that are in rdf terms sub-properties of prev, next, etc... On the atom-owl mailing list we are working on a very faithful onotology to the atom-syntax, that would allow this sub-property relation to be clearly stated. This keeps everything very nicely open, allowing many specialised semantics of the next, prev, style to be created. Henry On Mon, 17 Oct 2005, James M Snell 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 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 set. Fully agree. Let's use what MarkP wrote down over a year ago, and stop debating the nature of adjacency and ordering as it relates time and archives. Are there any technical problems with the elements in this feed: http://diveintomark.org/xml/2004/03/index.atom ;-) Woo hoo! Robert and I agree on something ;-) 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 as I discovered with my Feed Index extension proposal. * Next/Prev/Start/Subscribe defines a linked list of feed documents and/or entry documents and says absolutely nothing about the ordering of the entries. * Next/Prev/Start/Subscribe should be defined in their own specification that is not bound to Feed History * Feed History (if MarkN wishes it so) should normatively reference the Next/Prev/Start/Subscribe extension spec 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 the next week I'll see if I can draft up the spec. I'll use what MarkP put together as the basis for what I write up and submit. - James
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 entries are from an earlier time. If when following the next link the updated time stays the same, then the client can assume this is just more of the same collection from the previous point in time (unordered collection). Just a thought... Brett Lindsley, Motorola Labs.
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 term), if the updated time gets older, then the client can understand these entries are from an earlier time. If when following the next link the updated time stays the same, then the client can assume this is just more of the same collection from the previous point in time (unordered collection). Just a thought... Won't work -- older date-paged archives may have an entry updated anytime in the future, and thus not only does that entry get a more recent atom:updated than any entries intervening then and now, but the feed itself will also get a more recent atom:updated. e.
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 in HTML. I'm still not exactly sure which of the two options you're in favour of. This is the reason why the point is being debated - it's not immediately obvious which way is most consistent with usage elsewhere. Nottingham or Pilgrim? 2. Are next and prev both needed in the spec if we only require one of them to reconstruct the full history? Knowing that the most recently published archive won't likely remain the most recently published archive, there will be use cases where it's better to reconstruct the full history by starting at the one end which is fixed. Not much sense starting at the other end which is constandly shifting. The way I understand it, both sides are fixed as soon as there is at least one archive. At the one end you have the oldest archive. At the other end you have the current syndication document (to which the end-user would subscribe). Both URIs are fixed. The most recent archive will keep changing over time, but that is the second item in the list (or second last, depending on which direction you prefer to travel). 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 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) would point to the archive document with the top 10 books from last month. Personally I think that is an issue that should be argued and subsequently specified in a separate proposal on the use of non-incremental feeds. Just make sure the history spec is open enough to allow for either possibility once it is decided. Regards James
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 chapters or sections rendered in HTML. I'm starting to think that the way to fix this is to make it more specific, so that it doesn't get conflated with other uses; e.g., prev-archive. -- Mark Nottingham http://www.mnot.net/
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. Consider the use of 'first/next/prev/last' with chapters or sections rendered in HTML. I'm still not exactly sure which of the two options you're in favour of. This is the reason why the point is being debated - it's not immediately obvious which way is most consistent with usage elsewhere. Nottingham or Pilgrim? hmmm ... I did say Consider the use of 'first/next/prev/last' with chapters or sections rendered in HTML... Chapter #1 comes first, followed by chapter #2, and you go from chapter #1 through to chapter #nnn via 'next'. Think too of Pepys' Diary. What would you consider the 'first' entry? Would the 'first' entry be 1st January 1660, or would it be 16th October 1662? Note well though that sometime tomorrow the latter point would be neither 'first' or 'last' because there would be a new entry for the 17th October 1662 (and yet another one the day after). 2. Are next and prev both needed in the spec if we only require one of them to reconstruct the full history? Knowing that the most recently published archive won't likely remain the most recently published archive, there will be use cases where it's better to reconstruct the full history by starting at the one end which is fixed. Not much sense starting at the other end which is constandly shifting. The way I understand it, both sides are fixed as soon as there is at least one archive. At the one end you have the oldest archive. At the other end you have the current syndication document (to which the end-user would subscribe). Both URIs are fixed. What I mean by fixed is that it doesn't move or change as the set grows. Adding one onto the end and resetting where 'last' points to means that 'last' is *not* fixed. What you mean is that as soon as there is at least one archive then both ends are *established*. One end is fixed, and the other will grow. 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 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) would point to the archive document with the top 10 books from last month. That makes sense. Personally I think that is an issue that should be argued and subsequently specified in a separate proposal on the use of non-incremental feeds. Just make sure the history spec is open enough to allow for either possibility once it is decided. I agree. So .. the issue of (not-)incremental is orthogonal to feed history then. e.
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 article used next. 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 in HTML. ...so do you follow forward through time or backward? Is the starting current position now or the the beginning of time? Especially if we're talking about history, following backward makes as much sense as following forward. I prefer next to go back in time (if temporally ordered--from the most current chunk to the next most current chunk) or to less significant pages (in things like search results). But I'll probably have to stop and think what next means in temporally ordered feeds from time to time since it'd be the reverse of temporal order. 2. Are next and prev both needed in the spec if we only require one of them to reconstruct the full history? Knowing that the most recently published archive won't likely remain the most recently published archive, there will be use cases where it's better to reconstruct the full history by starting at the one end which is fixed. Not much sense starting at the other end which is constandly shifting. Is this only going to be used to reconstruct full history? What about just reconstructing the last 3 months (in which case you'd want a link from closer to the live end to close to the fixed end), or reading from the beginning before deciding whether to continue reading what comes later (in which case you'd want a link from closer to the fixed end to closer to the live end). 3. Are the first/last relationships needed? See (2) above for 'first'. Meanwhile 'last' could be followed by a user to jump ahead to the end of the set of archives to see if the butler did it. Who said 'first/next/prev/last' would only be used by machines? As mentioned above, there may be cases where you'd prefer to start at either the fixed or live end, so as long as complete feed reconstruction isn't the only goal, I'd say yes. But what's first? It'd be the top results in a search feed, but would it be the start of time or the start from the present (before possibly traveling backward through time) in a temporally ordered feed? Making it the start of time would prevent it from matching up well with how significance ordered feeds match up (ie. does start point to the thing you'd most likely want to see if you subscribed to the feed?) If we're not careful, we'll be traversing out of first through prev and last through next! 4. Is the order of the entries in a feed relevant to this proposal? not to this proposal. If you mean not just the order within each chunk of the feed, but the order of the chunks, then not central, but certainly related. Two cases come to mind: 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 entire chain shifts around all the time. If you're not going to reconstruct the whole thing, then your decision function for when to stop may have to be different depending on how things are ordered. BTW, case 2 destroys the idea of a fixed end and a live end. Having a means to indicate what the ordering is might make it easier to make the distinction between next and prev more intuitive. I'm not sure how else we're going to reconcile terminology for significance and temporally ordered feeds. 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 week's top ten on the first page, last week's ten on the second page... Since this proposal is defining a paging mechanism, I think that what each page represents is relevant. Is it an earlier part of the feed or an earlier state of the feed? 6. What to name the link relation that points to the active feed document? subscribe, subscription, self, something else? 'subscribe' I just noticed something about the definition of self in the format spec. In one place it says: o atom:feed elements SHOULD contain one atom:link element with a rel attribute value of self. This is the preferred URI for retrieving Atom Feed Documents representing this Atom feed. Does that mean that it's the preferred optionsubscription/option URI, or the preferred place to retrieve optionthis chunk/option of the feed history? The format spec didn't define paging, so it didn't
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 entire chain shifts around all the time. If you're not going to reconstruct the whole thing, then your decision function for when to stop may have to be different depending on how things are ordered. BTW, case 2 destroys the idea of a fixed end and a live end. Having a means to indicate what the ordering is might make it easier to make the distinction between next and prev more intuitive. I'm not sure how else we're going to reconcile terminology for significance and temporally ordered feeds. Okay, I've got another idea--switch to totally generic terminology, a la: end-a: the URI of most significant, most current, prerequisite[1], etc. end of a sequence of documents, or a randomly selected end if there is no order. end-b: the URI of the least significant, least current, or ...uh, postrequisite? end of a sequence of documents or otherwise the opposite end from end-a. a-ward: the URI of the document next closest to end-a in the sequence. b-ward: the URI of the document next closest to end-b in the sequence. If you have neither end-a nor end-b, then you should use b-ward to traverse out of the subscription document (ie. the subscription document in that case is assumed to be end-a). [1] if the sequence should be read first to last, for example, if it's a novel broken down into entries, end-a points to the place from which one should start. Which end is end-a and which is end- b is somewhat subjective. For example, in a temporally ordered feed, is it most important to read what's most current, or to understand the origins of the present first before reading what's most current? One more thing occurs to me--if this extension is going to be used to handle things like paging in search results, then it's not really feed history, it's paging.
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 'first/next/prev/last' with chapters or sections rendered in HTML. ...so do you follow forward through time or backward? Is the starting current position now or the the beginning of time? Especially if we're talking about history, following backward makes as much sense as following forward. You can start wherever you want, but the @rel='first' archive is the archive which contains the first entry that ever existed. Why would the @rel='first' archive contain the last entry created, that makes no sense. If you want to go backwards in time, then the next archive would be found by following the @rel='prev' link .. because you are going backwards! I prefer next to go back in time (if temporally ordered--from the most current chunk to the next most current chunk) or to less significant pages (in things like search results). But I'll probably have to stop and think what next means in temporally ordered feeds from time to time since it'd be the reverse of temporal order. You're also likely to get confused when comparing Atom archives against their HTML versions ... because in the HTML world the '@rel=first' page is conventionally the oldest page, and the @rel='next' page traverses forward in time. But what's first? It'd be the top results in a search feed, but would it be the start of time or the start from the present (before possibly travelling backward through time) in a temporally ordered feed? Making it the start of time would prevent it from matching up well with how significance ordered feeds match up (ie. does start point to the thing you'd most likely want to see if you subscribed to the feed?) If we're not careful, we'll be traversing out of first through prev and last through next! 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 would likely now be even more entries into this thread, so where would you then read them from ... where you started and going forward in time, or would you jump to the most recent and then read backwards until you hit a message you already read? So, would you read the messages in this order: 7,6,5,4,3,2,1,8,9,10,11,12,13,14 or... 7,6,5,4,3,2,1,11,10,9,8,13,12,14 or... 1,2,3,4,5,6,7,8,9,10,11,12,13,14 I know which way I'd prefer to read stuff. e.
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 you were looking at an historical chunk, you would still need some link to where you might subscribe to that feed. So, if polymorphic, you'd have in the current living chunk a link of 'self' to subscribe to, but in a historical chunk you'd need to ignore the 'self' link and follow the 'subscribe' link instead. If not polymorphic, in the current living chunk you'd have a 'subscribe' link, and in a historical chunk you'd have a 'subscribe' link. They would both mean the same thing, and have the same value. In the historical chunk the 'self' link would be different from the 'subscribe' link (pointing at the historical chunk, of course), but in the current living chunk they could very well have the same value ... or not... The or not case is best exemplified by the nature.com feed links. If you want to subscribe to Nature Medicine, you'd use this URI ... http://www.nature.com/nm/current_issue/rss/ ... but if you were to attempt to retrieve that URI today you would find yourself redirected to ... http://www.nature.com/nm/journal/v11/n10/rss.rdf ... where, if were atom, you might find a 'self' link pointing to that second URI, not the first. The nature.com feeds are, btw, a rather good real-life example of non-incremental feeds. e.
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. geeking Technically, they wouldn't necessarily be closed sets. Tim Bray, search god that he is, has explained in some blog post somewhere that the smart thing to do is simply find the first hundred or so results, sort them, and only when the user asks for more pages to bother going off and finding more results to add to the collection. It's complicated, I think I understood it for all of 10 seconds after I finished reading it, and it only really applies to searching massive collections ... searches in more finite collections would be, could be, completely closed sets. /geeking e.
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 would likely now be even more entries into this thread, so where would you then read them from ... where you started and going forward in time, or would you jump to the most recent and then read backwards until you hit a message you already read? 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. It's not going to try and read the messages and make sense of them. It just wants to retrieve all the documents in the most efficient way possible. First off is has to start with the most recent document since that's what the user is going to subscribe to. From there, the most sensible thing to do would be to keep following links back in time to older and older archives until it has retrieved all of them or (if this is a feed that has been downloaded before) until it reaches an archive that it has previously retrieved. While it's theoretically possible to obtain a link from the subscription document back to the oldest archive and then make your way forward in time that wouldn't be very efficient when you've most likely already retrieved all of those old archives. From an aggregator's point of view, you really don't have that much choice - going backwards in time is the only sensible thing to do. Which is why aggregator developers tend to think of the most recent document as first, and subsequent documents (back in time) as next. Technically these documents don't even have to be archives - they could just as easily be chunks of search results. The dates on the messages don't even come into play - an Atom processor wouldn't treat them any differently. I don't dispute that you have valid reason for thinking that forwards in time is the way to go, but please don't assume those of us that think the opposite are necessarily insane. Regards James
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 a result set. Fully agree. Let's use what MarkP wrote down over a year ago, and stop debating the nature of adjacency and ordering as it relates time and archives. Are there any technical problems with the elements in this feed: http://diveintomark.org/xml/2004/03/index.atom Works for me. Can anyone tell us about problems this causes for their software? Robert Sayre
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 +% point; the rest can come in separate vehicles. Any response to 'prev-archive'? Cheers, On 17/10/2005, at 11:49 AM, Thomas Broyer wrote: 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 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) would point to the archive document with the top 10 books from last month. I think that Mark's concerns were that readers/aggregators generally keep a local history of the feeds they're subscribed to. fh:incremental=no would explicitly tell them not to do so. -- Thomas Broyer -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
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 backwards. Remember that by the time you've read back to the initial posting there would likely now be even more entries into this thread, so where would you then read them from ... where you started and going forward in time, or would you jump to the most recent and then read backwards until you hit a message you already read? 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 preference trump the human reader? I imagine a future where a client application would offer up feed documents rendered all pretty, and offer up any links to other feed documents as links the client application will itslef render rather than passing them to a HTML browser. Thus, a Feed Browser in the same sense as a HTML Browser. Do you want to explain to future users why the next link gives them last weeks news instead of next weeks news? It's not going to try and read the messages and make sense of them. It just wants to retrieve all the documents in the most efficient way possible. Do things efficiently then. Remember though that the computer does *not* care if the token is 'next' or 'prev' or even 'foobar'. Does *not* care. First off is has to start with the most recent document since that's what the user is going to subscribe to. From there, the most sensible thing to do would be to keep following links back in time to older and older archives until it has retrieved all of them or (if this is a feed that has been downloaded before) until it reaches an archive that it has previously retrieved. Did you say back in time? Your explanation is riddled with references to going backwards .. the aggregator/developer frame of reference is going backwards, so of course the next object would be the one marked as being prior to the one your are currently on. That is, the next feed to process is the one marked @rel='prev'. Depending on what meta-data is available, and which axis you wish to traverse, and in which direction, then the link to the object you wish to retrieve after processing the current one could be next, prev, hotter, colder, or foobar. The usage of the word next in describing the sequence of actions is entirely dependent on the purpose of those actions, and quite possibly completely detached from the meaning of the content being processed. The @rel='next' and @rel='prev' links however are part and parcel of the content. They describe the content. They are provided by the content publisher. They don't describe some third party's desired course of action. I don't dispute that you have valid reason for thinking that forwards in time is the way to go, but please don't assume those of us that think the opposite are necessarily insane. But that would take all the fun out of things ;-) e.
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 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 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 oldest entries, it doesn't matter. My Atom processor would just Do The Right Thing with whatever entries it finds in the feeds as it walks through the linked list of feed documents. How does the Atom processor know when it has the complete history? Either a) the user tells it to stop or b) it reaches a feed without a next link. There shouldn't be any requirement that the entries in a feed (or even the feed documents themselves) have to be in a specific order in order to reconstruct the history. The minimum requirement is only that we're able to find the feed documents we need. The Atom processor can figure the rest out from there. - James Mark Nottingham wrote: 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 +% point; the rest can come in separate vehicles. Any response to 'prev-archive'? Cheers, On 17/10/2005, at 11:49 AM, Thomas Broyer wrote: 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 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) would point to the archive document with the top 10 books from last month. I think that Mark's concerns were that readers/aggregators generally keep a local history of the feeds they're subscribed to. fh:incremental=no would explicitly tell them not to do so. -- Thomas Broyer -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems _ ___ BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec -- Mark Nottingham http://www.mnot.net/
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 default sort order of a result set. Fully agree. Let's use what MarkP wrote down over a year ago, and stop debating the nature of adjacency and ordering as it relates time and archives. Are there any technical problems with the elements in this feed: http://diveintomark.org/xml/2004/03/index.atom ;-) Woo hoo! Robert and I agree on something ;-) 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 as I discovered with my Feed Index extension proposal. * Next/Prev/Start/Subscribe defines a linked list of feed documents and/or entry documents and says absolutely nothing about the ordering of the entries. * Next/Prev/Start/Subscribe should be defined in their own specification that is not bound to Feed History * Feed History (if MarkN wishes it so) should normatively reference the Next/Prev/Start/Subscribe extension spec 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 the next week I'll see if I can draft up the spec. I'll use what MarkP put together as the basis for what I write up and submit. - James
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 different pages of the present. In a non- incrememental feed also, we may have multiple pages of current entries (eg. the top 100 DVDs in chunks of 10), or we may have just one. We also may preserve historical data (eg. the top 10 songs last week, the week before, etc.) So what we end up with might looks like this: Any feed, whether incremental or not, MAY contain something like this (names chosen somewhat arbitrarily, with an eye toward avoiding excess conceptual baggage): page-a - the URI of one end of a chain of documents representing one state of a feed resource (eg. the current state of an incremental feed)--it doesn't really matter which end it is page-b - the other end of the chain of documents page++ - the next farther page from page-a page-- - the next closer page to page-a Neither page-a nor page-b is necessarily fixed--the entire contents of the chain may shuffle around, be added to, be deleted from, etc., in the case of something like search results. A non-incremental feed MAY also contain something like this (history is temporal, so we can use temporally loaded terminology): history-1 - a document containing a representation of one of the ends of or the entire temporally first historical state of the feed resource history-n - a document containing a representation of one of the ends of or the entire temporally last (perhaps current and still changing) historical state of the feed resource history++ - one of the ends or ... of the the next more recent historical state... (moves toward history-n) history-- - one of the ends ... of the next less recent historical state... (moves toward history-1) If you want to catch up on an incremental feed to which you're subscribed, or want to get the last month of an incremental feed to which you are newly subscribed, you look for page++ or page-- and follow whichever one the subscription document (which can only have one, since it's one of the ends) contains till you've got everything you want. If you start in the middle, you don't know which direction you're going...but since the ordering of the chain isn't defined, it's like the Cheshire cat says--it doesn't matter which direction you go if you don't know where you want to end up...or something like that. Perhaps convention could dictate that page-a be where the publisher subjectively thinks that a newcomer to the feed would be most likely to want to start reading. It wouldn't always be correct, but so what?
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 specific, and I think that's a bad thing. It seems to introduce tower of babel problems. Robert Sayre
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 nice 80+% point; the rest can come in separate vehicles. Any response to 'prev-archive'? Question: is what you want really a link to archives or isn't it just simple paging through a feed? I suspect it is the latter, because reconstructing feed state is only needed if a complete set of entries is split into several documents. Therefore, I'll rather suggest moving to: - a spec about paging, defining head/prev/next (do we really need tail?) [note: see with A9/OpenSearch people] - a spec defining fh:incremental, describing relation to paging (can a non-incremental feed be paged? does it mean something different than paging of an incremental feed?) - eventually a spec defining links to archives (which in turn may use paging: think about archives of search results, what did the same query return yesterday, last week, last month, etc.) -- Thomas Broyer
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 whatever else may come up, then I would favor the use of the generic mechanism assuming that the basic function is the same. - James Mark Nottingham 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. As it is, no one has even noticed it had similarity to this proposal until a few days ago, and it looks like there are a number of people who have strong feelings each way. OTOH, how specific the relation is *is* a technical issue; could you expand on what you see as the 'tower of babel' problem? 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 different way? To put it in Thomas' terms, what if there are different concepts of paging using the same terms -- which there seem to be already? This shows up perfectly with the whole next or previous? discussion. If we don't assign specific, functional semantics to the links, people will interpret -- and use -- them differently. This is why I'm leaning towards prev-archive. On 17/10/2005, at 1:15 PM, Robert Sayre wrote: 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, and I think that's a bad thing. It seems to introduce tower of babel problems. Robert Sayre -- Mark Nottingham http://www.mnot.net/
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]
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 perfectly clear. Is there something about it you don't understand? I do think your addition of an indicator that the feed is an archive is a good idea. I have to disagree with your characterization of deployment. Most AtomAPI implementations work this way--see for example typepad.com. 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 different way? To put it in Thomas' terms, what if there are different concepts of paging using the same terms -- which there seem to be already? This shows up perfectly with the whole next or previous? discussion. If we don't assign specific, functional semantics to the links, people will interpret -- and use -- them differently. Folks who have written Atom clients know which way 'next' points. This is why I'm leaning towards prev-archive. Mmm. I think 'prev-archive' means exactly the same thing that 'next' does in the feeds you're describing, and people will certainly use it in ways that don't reflect whatever you lay out in the spec. They will look at a feed, and think oh, I use prev-archive to get the next 10. I know for a fact that other feeds So, now we have two ways to say the same thing -- The Tower of Babel problem. http://tantek.com/log/2005/07.html#towerofbabelproblem Robert Sayre
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 is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: Undefined. - Security considerations: Because automated agents may follow this link relation to construct a 'virtual' feed, care should be taken when it crosses administrative domains (e.g., the URI has a different authority than the current document). - Attribute Value: next - Description: A stable URI that, when dereferenced, returns a feed document containing entries that sequentially follow those in the current document. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: Undefined. - Security considerations: Because automated agents may follow this link relation to construct a 'virtual' feed, care should be taken when it crosses administrative domains (e.g., the URI has a different authority than the current document). - 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 ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: - Security considerations: - Attribute Value: last - Description: A stable URI that, when dereferenced, returns a feed document containing those entries furthest following those in the current document at the time it was minted. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: Undefined. - Security considerations: +0.5 (adding the circular references issue raised by James), because some people will use first to link to the live feed (the one you subscribe to) and next to link to the first archive document and so on, and some will use last and prev for the exact same roles… The given definition is not precise enough. And wrt prev, why not previous? both could also be registered as aliases… - 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 feed document it exists in, it indicates a URi that should be used for this purpose in place of the current document's URI. - Expected display characteristics: Undefined. - Security considerations: Users should always be informed of the actual URI they are subscribing to, and subscription should only take place when it is explicitly requested. 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 @rel=first (or last?) – or I missed something… -- Thomas Broyer
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 feed document it exists in, it indicates a URi that should be used for this purpose in place of the current document's URI. - Expected display characteristics: Undefined. - Security considerations: Users should always be informed of the actual URI they are subscribing to, and subscription should only take place when it is explicitly requested. 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 @rel=first (or last?) – or I missed something… self should always point to the feed document containing the self link. It makes no sense to have a self link in a feed that does not point to itself. - James
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 pops up :) On 17/10/2005, at 3:21 PM, Thomas Broyer wrote: I don't think there are different concepts of paging. Paging is navigation through subsets (chunks) of a complete set of entries. 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 allows for feed state reconstruction. In other terms, feed state reconstruction is a facet of paging, an application to non-incremental feeds. I think it's worth waiting consensus on previous/next or forwards/ backwards, first/last or head/tail, etc. and having a paging spec (or just IANA registration, I don't really matter), and orthogonally define an fh:incremental extension (fh:incremental will just change newsreaders behavior, not the paging concept). It seems James is having the same feeling… -- Mark Nottingham http://www.mnot.net/
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 so if/when this problem pops up :) Be sure to throw a neener neener neener into it and we're good to go ;-) - James
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 different way? To put it in Thomas' terms, what if there are different concepts of paging using the same terms -- which there seem to be already? I don't think there are different concepts of paging. Paging is navigation through subsets (chunks) of a complete set of entries. 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 allows for feed state reconstruction. In other terms, feed state reconstruction is a facet of paging, an application to non-incremental feeds. I think it's worth waiting consensus on previous/next or forwards/backwards, first/last or head/tail, etc. and having a paging spec (or just IANA registration, I don't really matter), and orthogonally define an fh:incremental extension (fh:incremental will just change newsreaders behavior, not the paging concept). It seems James is having the same feeling… -- Thomas Broyer
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 -- same as your pushback on prev. *shrug* The SixApart people have publicly pointed to FH, so I don't think they're particularly fussed about any particular approach other (not to put words in their mouth). I wasn't able to find a TP feed that uses rel=next; do you have a link to one? If the WG registers a set of generic link relations (I still have that concern, but again, if there's consensus in the WG, I'm happy to abide by it), it effectively reduces FH to a users' guide for one use of those extensions, and would probably say something like walk down and next or prev you see in the subscription feed. The only normative bit would probably be fh:incremental. Cheers, On 17/10/2005, at 3:21 PM, Robert Sayre wrote: I think the spec is perfectly clear. Is there something about it you don't understand? I do think your addition of an indicator that the feed is an archive is a good idea. I have to disagree with your characterization of deployment. Most AtomAPI implementations work this way--see for example typepad.com. -- Mark Nottingham http://www.mnot.net/
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 ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: - Security considerations: - Attribute Value: last - Description: A stable URI that, when dereferenced, returns a feed document containing those entries furthest following those in the current document at the time it was minted. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: Undefined. - Security considerations: +0.5 (adding the circular references issue raised by James), because some people will use first to link to the live feed (the one you subscribe to) and next to link to the first archive document and so on, and some will use last and prev for the exact same roles… The given definition is not precise enough. 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 document at the time it was minted. The set of entries in this document should not change over time; i.e., this link points to a stable snapshot of entries, or an archive of feed entries. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: ... - Security considerations: ... Another thought would be first-archive, last-archive, prev- archive and next-archive (just expanding a previous thought). And wrt prev, why not previous? both could also be registered as aliases… I'd prefer one or the other; don't care much which it is, but two seems wasteful. HTTP-WG didn't alias Referer even tho it's spelled incorrectly, for example. That worked out OK. - 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 feed document it exists in, it indicates a URi that should be used for this purpose in place of the current document's URI. - Expected display characteristics: Undefined. - Security considerations: Users should always be informed of the actual URI they are subscribing to, and subscription should only take place when it is explicitly requested. 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… I think there's value in the current reading of self; it's sometimes useful for a document to know what URI it's available at. Also, when it occurs in another feed, self is a very non-obvious name for what's happening. Otherwise, +0.5, because it seems to overlap @rel=first (or last?) – or I missed something… I think we're kind of short on use cases for first and last, but people seem to want them. 'subscribe' is more explicit; as they're written, 'first' and 'last' should definately NOT be subscribed to (because the set of entries in them won't change). Cheers, -- Mark Nottingham http://www.mnot.net/
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 document at the time it was minted. The set of entries in this document should not change over time; i.e., this link points to a stable snapshot of entries, or an archive of feed entries. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: ... - Security considerations: ... Another thought would be first-archive, last-archive, prev- archive and next-archive (just expanding a previous thought). -1. The first/next/prev/last link rels should not specify any restrictions on how the contents of the feeds should or should not be updated. If a specific use of these link rels wishes to impose such a restriction (e.g. for feed history), then great, so-be-it, but the link rels themselves should not. And wrt prev, why not previous? both could also be registered as aliases… I'd prefer one or the other; don't care much which it is, but two seems wasteful. HTTP-WG didn't alias Referer even tho it's spelled incorrectly, for example. That worked out OK. +1, it doesn't matter... but I do prefer previous because I don't like abbreviations in things like this Otherwise, +0.5, because it seems to overlap @rel=first (or last?) – or I missed something… I think we're kind of short on use cases for first and last, but people seem to want them. 'subscribe' is more explicit; as they're written, 'first' and 'last' should definately NOT be subscribed to (because the set of entries in them won't change). +1 - James
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?
http://www.imc.org/atom-syntax/mail-archive/msg17249.html
I wasn't able to find a TP feed that
uses rel=next; do you have a link to one?
They use them in their AtomAPI implementation, not the public feeds.
http://www.sixapart.com/pronet/docs/typepad_atom_api
http://www.typepad.com/t/atom/weblog/blog_id={blogid} points to the
20 newest entries. There's a link rel=next in there that points to
the next 20 entries.
Robert Sayre
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 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 solve the feed subscription problem. However, I don't recall that the issue of feed archives featured much in that discussion, and that thus the now understood problem of 'self' vs 'subscribe' wasn't envisaged. Fortunately, the link relation 'self' was defined in such a woolly way we could get away with re-purposing it. A few articles here or there, a bit of blog chatter, and the arrival of the fabled Developers Guide and we'd be set. I'd think this would be favourable to having to come up with a different pair of relations, like 'self' = what you subscribe to, may not look anything like the chunk in front of you 'this-chunk' = link to what you are looking at, not to be confused with 'self' (Maybe the Developers Guide will have a chapter called Up Is Down - The New Reality, which would explain that a link to 'self' doesn't, we use 'next' to go backwards, and 'alternate' for feed discovery may not point to actual alternates of the content in front of you ;-) Otherwise, +0.5, because it seems to overlap @rel=first (or last?) – or I missed something… There's nothing wrong with having an overlap like this, because they don't always overlap. Consider the 'subscribe' link to nature.com/nm/ which I described earlier - two different URIs, but the same eventual document. e. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
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 set of entries furthest preceding those in the current document at the time it was minted. This can be thought of as specific to those entries; in other words, it represents a fixed section of the feed, rather than a sliding window over it. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: ... - Security considerations: ... It's a hard line to walk. 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. - James
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 I get to say I told you so if/when this problem pops up :) I share your concern. On 17/10/2005, at 3:21 PM, Thomas Broyer wrote: I don't think there are different concepts of paging. Paging is navigation through subsets (chunks) of a complete set of entries. 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. 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 allows for feed state reconstruction. In other terms, feed state reconstruction is a facet of paging, an application to non-incremental feeds. Let's say you're doing a feed for the Billboard top 100 songs. Each week, the entire contents of the feed are swapped out and replaced by a new top 100 (ie. it is a non-incremental feed). And let's say you don't want to put all 100 in the same document, but you want to break it up into 4 documents with 25 entries each. You now have two potential axes that people might want to traverse--from songs 1-25 to 26-50 to 51-75 to 76-100, or from this weeks 1-25 to last weeks 1-25 to two weeks ago's 1-25, etc. You can't link in both directions with the same next. There are clearly two distinct concepts here--navigating through the chunks that make up the current state of the feed resource, and in a non-incremental feed, navigating though the historical states of the feed resource.
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 resource equivalent to the containing element. thus a link with @rel='self' in the feed element would link to that archive feed document. Similarly, a link with @rel='self' in the entry element would link to a resource document of that particular entry. Thus (in context of feed) 'self' = identifies a resource equivalent to this feed 'subscribe' = identifies the resource to subscribe to The same holds true for archive feeds and the current sliding window chunk, which makes life easier. e.
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- significance into the feed is going to fail... just as I discovered with my Feed Index extension proposal. Here's what the spec says: This specification assigns no significance to the order of atom:entry elements within the feed. ...but there may be some. ...but there's no action you can take based on it unless something else tells you what the significance is. ...which, yes, is very difficult to specify. For the purposes of this discussion, it doesn't matter what the order of atom:entry elements within a feed document is. But the order of chunks of atom:entry elements within a linked series of feed documents may have significance, and in fact, unless you just want to reconstruct the complete feed state, working with a series of feed documents with no specific order would be fairly unwieldy. Imagine paging though a feed of search results with no idea of whether you'd just jumped from the most to the least significant results, or to the second most significant results. Imagine trying to catch up on a fast-moving incremental feed without having any idea whether a link would take you to the first entries ever added to a feed or the one's you just missed. I do believe that a last link relation would be helpful for completeness ...and last certainly seems to imply SOME sort of ordering of chunks, even if we know nothing about the order of the entries in each chunk. To each of the following, perhaps we could add something to indicate that these link relations are all used to page through the current state of a feed, and not to navigate among various states of a feed. The fact that most people wouldn't have a clue what that means without some discussion of incremental and non-incremental feeds may be an argument for having a spec document to provide more explanation (rather than embedding an identical explanation in each Description). Example: At any point in time, a feed may be represented by a series of Feed documents, each containing some of the entries that exist in the feed at that point in time. In other words, a feed may contain more entries than exist in the Feed document that one retrieves when dereferencing the subscription URI, and there may be other documents containing representations of those additional entries. The link relations defined in this specification are used to navigate between Feed documents containing pages or chunks of those entries which exist simultaneously within a feed. Note that this specification does not address navigation between the current and previous states of a type of feed which does not simultaneously contain it's current and past entries. For example, a Top 100 Songs feed might at any point in time only contain entries for the top 100 songs for a single week, which entries may or may not be divided among a number of Feed documents. The entries for the top 100 songs from the previous week are not only no longer part of the Feed document or Feed documents representing the current state of the feed--they are no longer part of the feed at all. Another specification may describe a method of navigating between the current and previous states of such a feed. The link relations defined in this specification are only used to navigate between the various Feed documents representing any single state of such a feed. - 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 is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: Undefined. - Security considerations: Because automated agents may follow this link relation to construct a 'virtual' feed, care should be taken when it crosses administrative domains (e.g., the URI has a different authority than the current document). - Attribute Value: next - Description: A stable URI that, when dereferenced, returns a feed document containing entries that sequentially follow those in the current document. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: Undefined. - Security considerations: Because automated agents may follow this link relation to construct a 'virtual' feed, care should be taken when it crosses administrative domains (e.g., the URI has a different authority
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 extension to retrofit order- significance into the feed is going to fail... just as I discovered with my Feed Index extension proposal. Here's what the spec says: This specification assigns no significance to the order of atom:entry elements within the feed. ...but there may be some. ...but there's no action you can take based on it unless something else tells you what the significance is. ...which, yes, is very difficult to specify. Not only difficult to specify, impossible to enforce. There's no way we can expect implementations to preserve the order of entries For the purposes of this discussion, it doesn't matter what the order of atom:entry elements within a feed document is. But the order of chunks of atom:entry elements within a linked series of feed documents may have significance, and in fact, unless you just want to reconstruct the complete feed state, working with a series of feed documents with no specific order would be fairly unwieldy. Imagine paging though a feed of search results with no idea of whether you'd just jumped from the most to the least significant results, or to the second most significant results. Imagine trying to catch up on a fast-moving incremental feed without having any idea whether a link would take you to the first entries ever added to a feed or the one's you just missed. That's what incremental=true is for, or the feed rank mechanism, etc. Basically, the next/prev mechanism should be used in conjunction with something else that specifies the ordering of the entries, etc. The next/prev link relations should imply nothing more than a linked list of feeds. I do believe that a last link relation would be helpful for completeness ...and last certainly seems to imply SOME sort of ordering of chunks, even if we know nothing about the order of the entries in each chunk. Nope. It implies nothing more than a closed-set linked list of feeds. No ordering is implied. We could achieve the same result with rel=start and rel=end To each of the following, perhaps we could add something to indicate that these link relations are all used to page through the current state of a feed, and not to navigate among various states of a feed. The fact that most people wouldn't have a clue what that means without some discussion of incremental and non-incremental feeds may be an argument for having a spec document to provide more explanation (rather than embedding an identical explanation in each Description). Example: 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 Feed History incremental=true element. In other words, this does not imply a feed history thing... feed ... link rel=next href=... / /feed this does... feed ... fh:incrementaltrue/fh:incremental link rel=next href=... / /feed At any point in time, a feed may be represented by a series of Feed documents, each containing some of the entries that exist in the feed at that point in time. In other words, a feed may contain more entries than exist in the Feed document that one retrieves when dereferencing the subscription URI, and there may be other documents containing representations of those additional entries. The link relations defined in this specification are used to navigate between Feed documents containing pages or chunks of those entries which exist simultaneously within a feed. Again, you're thinking in terms of Feed History. I'm separating the link rel's out from Feed History and making them more generic. I would fully expect that the Feed History spec would define some ordering and processing semantic for the linked documents. - James
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 Feed History incremental=true element. I don't think I expressed the point I wanted to make quite clearly enough, so let me try again. Chains of Feed documents are going to be ordered in some way, whether it's specified or not, whether they explicitly indicate it or not. For example, the chain of Feed documents representing an incremental feed is going to naturally be in temporal order. You're not going to be tacking on new entries willy nilly to whichever of the documents in the chain fits your fancy at the moment. You're going to create a new document when the one you were most recently adding entries to gets full, and then your going to add entries there till that one is full, and so on. There may be exceptions, but by and large, whether the temporal order is explicit or not, that's what's going to happen. Chains of pages of search results feeds are going to naturally be ordered with the best matches on top. The point I was trying to make was that you're not going to create all the documents without links between then and then randomly assign links between them in no specific order. You're going to link between then in an order that makes sense within the context of how the feed was created. I don't know how client applications are going to adapt to deal with the difference between incremental feeds and, for example, search results feeds, but I can't imagine that client software isn't going to rely on there being some sort of sense to the order of the Feed documents. What I was trying to say further down with the example spec text I wrote was, let's state explicitly that this link relation does not have a temporal semantic, and if somebody want's a link relation with a temporal semantic, they should create another link/@rel value for it. In other words... In other words, this does not imply a feed history thing... ...let's have this be a link for navigating among the pages of the current state of the feed (whether it be incremental or not--noting that some non-incremental feeds will only have one page, and won't need it). The entries in the current state of the feed are not in any specific order (though we know that naturally they will be in some sort of order): feed ... link rel=next href=... / /feed How does the following have anything to do with history? In an incremental feed, all of the entries, whether part of the Feed document at the subscription end or not, are part of the present state of the feed--they don't just exist back in history. History is for non-incremental feeds. I'm saying let's not work on navigation through history right now, but let's recognize that unless we say not to, people might try to use the mechanism designed for paging through the current state of a feed to navigate through the history of a feed too, so let's say not to. I understand (or at least suppose) that you don't think we need to say not to, because you don't see the harm in making the link relation more generic. I disagree. I think we're going to end up with a mess if we don't make it specifically for navigating the current state. this does... feed ... fh:incrementaltrue/fh:incremental link rel=next href=... / /feed
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 starting to look better, as is fh:prev/. On 17/10/2005, at 9:17 PM, James M Snell wrote: In other words, this does not imply a feed history thing... feed ... link rel=next href=... / /feed this does... feed ... fh:incrementaltrue/fh:incremental link rel=next href=... / /feed -- Mark Nottingham http://www.mnot.net/
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 in the value of the href attribute identifies a resource equivalent to the containing element. thus a link with @rel='self' in the feed element would link to that archive feed document. Similarly, a link with @rel='self' in the entry element would link to a resource document of that particular entry. Thus (in context of feed) 'self' = identifies a resource equivalent to this feed 'subscribe' = identifies the resource to subscribe to The same holds true for archive feeds and the current sliding window chunk, which makes life easier. e. -- Mark Nottingham http://www.mnot.net/
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 author,... Again next, prev, first, last deal very well with paging. how do we specify the order? Is this related to the query? Should there be a default order for subscription feeds? Should the ordering information be specified in the feed? In rdf we could say things like iana:historicalNext a owl:ObjectProperty; rdfs:subPropertyOf iana:next; rdfs:comment a historically ordered next relation . and then use historicalNext for the particular historical ordering that we need to archive our feeds. This would allow processors who do not understand or care about the historical ordering to still walk through the linked list of feeds. Henry Ps. writing from Italy http://dannyayers.com/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 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 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 useful? An archive for a blog that is no longer being updated? An archive of entries pertaining to an event with a fixed endpoint? A discussion forum that has been closed. How are implementations supposed to use this information? Stop polling the feed? Consider its items immutable? I'm concerned if something so innocent-looking as last has these sorts of implications. perhaps a better example would then be a feed of search results, which at any time of query is a finite and closed set, and also designed to be paged through. e. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
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 author,... Again next, prev, first, last deal very well with paging. how do we specify the order? Is this related to the query? Should there be a default order for subscription feeds? Should the ordering information be specified in the feed? In rdf we could say things like iana:historicalNext a owl:ObjectProperty; rdfs:subPropertyOf iana:next; rdfs:comment a historically ordered next relation . and then use historicalNext for the particular historical ordering that we need to archive our feeds. This would allow processors who do not understand or care about the historical ordering to still walk through the linked list of feeds. Henry Ps. writing from Italy http://dannyayers.com/archives/2005/10/15/welcome-to-the-atomowl/ On Sat, 15 Oct 2005, Mark Nottingham 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? 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 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 useful? An archive for a blog that is no longer being updated? An archive of entries pertaining to an event with a fixed endpoint? A discussion forum that has been closed. How are implementations supposed to use this information? Stop polling the feed? Consider its items immutable? I'm concerned if something so innocent-looking as last has these sorts of implications. perhaps a better example would then be a feed of search results, which at any time of query is a finite and closed set, and also designed to be paged through. e. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
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 Atom Entry Documents. entry idtag:example.com,2005:/1/id link rel=next href=http://www.example.com/entries/2.entry; type=application/atom+xml / link rel=previous href=http://www.example.com/entries/0.entry; type=application/atom+xml / /entry The challenge comes when you want to link to entries that are contained within a feed, in which case, we could use xml:id feed ... entry xml:id=1 idtag:example.com,2005:/1/id link rel=next href=#2 type=application/atom+xml / /entry entry xml:id=2 idtag:example.com,2005:/1/id link rel=previous href=#1 type=application/atom+xml / /entry /feed Again, this is just used to build a simple linked-list of entries and does not imply any semantic order (e.g. order by date, order by significance, etc). the key challenge with this is that while I can definitely see how it would work, I'm having a hard time envisioning a use case for this. - James 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 alphabetical order of author,... Again next, prev, first, last deal very well with paging. how do we specify the order? Is this related to the query? Should there be a default order for subscription feeds? Should the ordering information be specified in the feed? In rdf we could say things like iana:historicalNext a owl:ObjectProperty; rdfs:subPropertyOf iana:next; rdfs:comment a historically ordered next relation . and then use historicalNext for the particular historical ordering that we need to archive our feeds. This would allow processors who do not understand or care about the historical ordering to still walk through the linked list of feeds. Henry Ps. writing from Italy http://dannyayers.com/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 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 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 useful? An archive for a blog that is no longer being updated? An archive of entries pertaining to an event with a fixed endpoint? A discussion forum that has been closed. How are implementations supposed to use this information? Stop polling the feed? Consider its items immutable? I'm concerned if something so innocent-looking as last has these sorts of implications. perhaps a better example would then be a feed of search results, which at any time of query is a finite and closed set, and also designed to be paged through. e. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
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 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 useful? An archive for a blog that is no longer being updated? An archive of entries pertaining to an event with a fixed endpoint? A discussion forum that has been closed. How are implementations supposed to use this information? Stop polling the feed? Consider its items immutable? I'm concerned if something so innocent-looking as last has these sorts of implications. perhaps a better example would then be a feed of search results, which at any time of query is a finite and closed set, and also designed to be paged through. e. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
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 reason to specify these things in Mark's draft. If they prove useful in implementations, they can be layered on the existing specs. Mark has his next/prev turned around, IMHO. link rel=next should go deeper into the past. Think of how you would write a SQL query with a limit clause. Robert Sayre
Re: Feed History -04
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, although it does require some careful wording. Also -- I'd think that the last link is already covered by self, no? If not, there's some pretty serious confusion about what 'self' means. On 13/10/2005, at 8:01 PM, Antone Roundy wrote: 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 (next/previous/first/last). 'first' or 'start'? 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, that's a good question. Maybe calling them top and bottom would work better. Considering that the convention is to put the newest entry at the top of a feed document, top might be more intuitively understandable as being the new end. You might also rename next and previous (or is it previous and next?) to down and up. There's SOME chance of that getting confused with hierarchical levels, but I could live with that. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
Re: Feed History -04
* 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 go fetch. If you really want this, don’t forget to to legislate this expectation. Otherwise some people may devise clever (or “clever”) stuff which breaks this expectation. Your example of breaking atom:[EMAIL PROTECTED]'self']/@href = atom:[EMAIL PROTECTED]'last']/@href is a perfect demonstration of how someone may do something legal that may break (naïve?) expectations. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed History -04
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 collection returned should be either newer (more recent updated time) or older (later updated time) with respect to the current collection doc. Wouldn't it be better to share the same link relations between feeds sorted by date/time or some other priority (e.g. OpenSearch results)? -- Thomas Broyer
Re: Feed History -04
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 something like that. That way, the collection returned should be either newer (more recent updated time) or older (later updated time) with respect to the current collection doc. A feed isn't necessarily a time-ordered sequence. Even a feed reconstructed using fh:prev (or a similar mechanism) could have its constituent parts generated on the fly, e.g., in response to a search query. The ordering of the entries may not matter, but the ordering of the documents does. Starting with the active feed document, you need to know whether you should be following a series of prev links or next links in order to traverse the archives back through time. While your feed history spec used prev for that purpose, previous implementations of atom:link appear to have used next. 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). I was going to suggest that initially but I don't think it's strictly true. The spec says that self identifies a resource *equivalent* to the containing element. Considering that an archived document and the active feed document will quite likely have no entries in common I think it's a bit of a stretch to claim them equivalent. Derived would be a better relationship IMHO. 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 need for a separate fh:archive flag, which in turn means that you don't have to declare two namespaces to use fh in RSS archive documents -- which was one of the things making me reluctant to switch over to atom:link. How about: atom:link rel=subscription href=.../ ? -- Mark Nottingham http://www.mnot.net/
Re: Feed History -04
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 containing element the same as an alternate version of the resource described by the containing element? 2. Is the answer to 1. is no then what does a resource equivalent … mean? Is it really different than the URI you should subscribe to (at least if @type=application/atom+xml)? -- Thomas Broyer
Re: Feed History -04
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 thing as what's in the containing element than to something you dereference to get a potentially completely different thing. Arguably, there is sometimes a use case for the current definition of self, so it's probably best to just define a new link relation. On 14/10/2005, at 10: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 containing element. 1. Isn't a resource equivalent to the containing element the same as an alternate version of the resource described by the containing element? 2. Is the answer to 1. is no then what does a resource equivalent … mean? Is it really different than the URI you should subscribe to (at least if @type=application/atom+xml)? -- Thomas Broyer -- Mark Nottingham http://www.mnot.net/
Re: Feed History -04
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 relationships in terms of time - such as newer and older or something like that. That way, the collection returned should be either newer (more recent updated time) or older (later updated time) with respect to the current collection doc. A feed isn't necessarily a time-ordered sequence. Even a feed reconstructed using fh:prev (or a similar mechanism) could have its constituent parts generated on the fly, e.g., in response to a search query. The OpenSearch case mentioned by Thomas is what convinced me that terms related to temporal ordering aren't appropriate (what a pity, since newer and older are the perfect terms for time ordered sequences of feed documents!) Previous and next suffer from the fact that they could easily be interpreted differently in different use cases. For example, for OpenSearch results pages, clearly prev points to the search results that come up on top and next to the lower results. But in a conventional syndication feed, next could easily be taken to mean either the next batch of entries as you track back towards the beginning of time from where you started (which is usually going to be the growing end of the feed), or a batch of entries containing the entries that were published next after the ones in this batch. I'd have to look at the document to remind myself of which next means, because either makes just as much sense to me. Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? Antone
Re: Feed History -04
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 containing element. That's what some of us wanted it to be and thought it was intended to be. The language that made it into the spec certainly falls short of expressing what was in PaceFeedLink, which is the proposal that added @rel=self [1]. 1. Isn't a resource equivalent to the containing element the same as an alternate version of the resource described by the containing element? That's how I would read that language knowing nothing of the history of that part of the spec. I think some people intended equivalent to mean it may not be a different copy of the same bits, but whatever it is, it contains the same bits (or at least the same code points, if it happens to be transcoded). 2. Is the answer to 1. is no then what does a resource equivalent … mean? Is it really different than the URI you should subscribe to (at least if @type=application/atom+xml)? I think what some people want that to mean is here's a place you could get the feed, but I'm not making any assertions regarding whether it's preferable to get it from there or somewhere else. [1] http://www.imc.org/atom-syntax/mail-archive/msg15062.html
Re: Feed History -04
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 XML.com discussing the Atom Link Model: http://www.xml.com/pub/a/2004/06/16/dive.html I can't say I've seen it widely used, but there is at least one occurrence in the wild (Mark's archives). 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 need for a separate fh:archive flag, which in turn means that you don't have to declare two namespaces to use fh in RSS archive documents -- which was one of the things making me reluctant to switch over to atom:link. How about: atom:link rel=subscription href=.../ Yeah, I think that's a great idea. I'm not sure about the name though. Would it not be better as a verb (say subscribe) since the link is effectively providing you with a url with which you can subscribe to the feed. This seems to me more in line with the verb-based link relations being used in the Atom publishing protocol. Admittedly in this case the link could just as easily be interpreted as a passive pointer to a document rather than an operation as such. I'm not really arguing strongly either way. Just something to think about. Regards James
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 all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
Re: Feed History -04
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 need for a separate fh:archive flag, which in turn means that you don't have to declare two namespaces to use fh in RSS archive documents -- which was one of the things making me reluctant to switch over to atom:link. How about: atom:link rel=subscription href=.../ Yeah, I think that's a great idea. I'm not sure about the name though. Would it not be better as a verb (say subscribe) since the link is effectively providing you with a url with which you can subscribe to the feed. This seems to me more in line with the verb-based link relations being used in the Atom publishing protocol. Admittedly in this case the link could just as easily be interpreted as a passive pointer to a document rather than an operation as such. I'm not really arguing strongly either way. Just something to think about. The idea is excellent. As for the naming sugar of the relation head, anchor or origin could work also. //Stefan
RE: Feed History -04
+1 The meaning of these terms depends so much upon the feed it is being used within. That and your own mental model. If you visualize a feed like this: --- | | | | | | | -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham Sent: 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 the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
RE: Feed History -04
I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. +1 Maybe this goes without saying, but I think the spec needs to either: a) define these terms clearly and how they should be used and interpreted (in which case it doesn't matter what words we use), or b) provide a mechanism for the feed to define their meaning relative to the feed (perhaps James' FeedRank extension is relevant here?) - i.e. this feed sorts items chronologically in ascending order. With that information, next and previous become more meaningful. Without either (a) or (b) then the meaning of whatever terms we choose will depend too much on the developer's mental model for feeds. For example, if you visualize a feed like this (e.g. a web page's chronologically sorted list): --- top | |- entry | |- entry | |- entry | --- bottom Then the terms up and down are quite meaningful, and next and prev a little ambiguous (am I top-down kinda guy, or a bottom-up?). Of course you then have to be clear to what top and bottom means. Then if you visualize feeds like this (like a linear timeline for example): ||||| entry | entry entry Then up and down are the terms that become less meaningful. Yadda yadda yadda. My feeling is that erring on the side of more broadly applicable, and semantically well know terms like next and previous will be more useful to extensions wishing to extend the metaphor or model for their own purposes (the FeedRank extension comes to mind specifically). I can even see value for a feed to specify more information about its result set: link rel=next href=foo?31-40 / link rel=previous href=foo?1-10 / result-set size10/limit start21/start end30/end total55/total sort/feed/entry/published/sort orderascending/order /result-set -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham Sent: 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 the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
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 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 collection returned should be either newer (more recent updated time) or older (later updated time) with respect to the current collection doc. A feed isn't necessarily a time-ordered sequence. Even a feed reconstructed using fh:prev (or a similar mechanism) could have its constituent parts generated on the fly, e.g., in response to a search query. The OpenSearch case mentioned by Thomas is what convinced me that terms related to temporal ordering aren't appropriate (what a pity, since newer and older are the perfect terms for time ordered sequences of feed documents!) Previous and next suffer from the fact that they could easily be interpreted differently in different use cases. For example, for OpenSearch results pages, clearly prev points to the search results that come up on top and next to the lower results. But in a conventional syndication feed, next could easily be taken to mean either the next batch of entries as you track back towards the beginning of time from where you started (which is usually going to be the growing end of the feed), or a batch of entries containing the entries that were published next after the ones in this batch. I'd have to look at the document to remind myself of which next means, because either makes just as much sense to me. True, but I don't think that means that the terms have to be abandoned, but that these examples need to be supported by spec text. That is, define 'next' as pointing to the next document in a series of documents, the whole series of documents containing a series of Atom Entries whose order is specific to the service providing it. -joe -- Joe Gregoriohttp://bitworking.org
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 should be made as to whether or not the entries in those feeds share any form of ordered relationship. link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: 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 surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
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 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 should be made as to whether or not the entries in those feeds share any form of ordered relationship. +1 link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: 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 surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
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 would support mnot's draft moving onto the standards track if it followed the linking scheme outlined by James. The RSS way of doing it could be kept alongside, if that's politically necessary. If Mark opts not to support atom:link, my support changes to silence, and I will go right ahead and implement the three link relations I need in my Atom implementations: next, prev, and profile. Robert Sayre
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 // http://plasmasturm.org/
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? Regards,
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) What's the relationship between these feed documents and the feed document that people subscribe to? I think the subscription feed needs to be pinned to one end of the set (which is what FH does now). Otherwise, it becomes difficult to figure out whether you have the complete set or not by polling. On 14/10/2005, at 3:16 PM, 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 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 should be made as to whether or not the entries in those feeds share any form of ordered relationship. link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: 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 surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems _ ___ BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
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 of if you want to subscribe to this feed, use the linked document, not this one. The reconstruction algorithm is pretty much the same as in -04. The only dangling point is first. I'm not especially against it, but what's the use case? On 14/10/2005, at 4:53 PM, 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 feed; see below). 2) What's the relationship between these feed documents and the feed document that people subscribe to? I think the subscription feed needs to be pinned to one end of the set (which is what FH does now). Otherwise, it becomes difficult to figure out whether you have the complete set or not by polling. On 14/10/2005, at 3:16 PM, 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 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 should be made as to whether or not the entries in those feeds share any form of ordered relationship. link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: 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 surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
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 needs in order to reconstruct the feed. I get that a feed producer may want to provide a non-incremental feed (top 10, todo lists, playlists, etc), but I don't see what that has to do with feed history. Wouldn't that be better suited in a separate extension along with whatever other meta-information might be appropriate for non-incremental lists? 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 to subscribe to this feed, use the linked document, not this one. The reconstruction algorithm is pretty much the same as in -04. The only dangling point is first. I'm not especially against it, but what's the use case? I'm not especially for it, but it's theoretically possible that someone subscribing to a feed for the first time may want to download the full archives. Depending on their processing model, this may be more convenient starting with the oldest archive and working forwards in time Regards James
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 get that a feed producer may want to provide a non-incremental feed (top 10, todo lists, playlists, etc), but I don't see what that has to do with feed history. Wouldn't that be better suited in a separate extension along with whatever other meta-information might be appropriate for non-incremental lists? It's more relevant than it seems at first glance. Currently, most (if not practically all) feed aggregators will keep a history by default, without information otherwise. Introducing a standard extension to enable that necessitates that there be a way to say don't do that. The only dangling point is first. I'm not especially against it, but what's the use case? I'm not especially for it, but it's theoretically possible that someone subscribing to a feed for the first time may want to download the full archives. Depending on their processing model, this may be more convenient starting with the oldest archive and working forwards in time Yeah, that's pretty much where I'm at; supplying effectively gives *two* ways to reconstruct the state of a feed, meaning that both would need to be supported (and optimised) by implementations, which isn't so great unless there's a compelling need for it. -- Mark Nottingham http://www.mnot.net/
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 subscription feed; see below). My answer would be: if last is used, it's a closed set; if last is not used, it's an open set. 2) What's the relationship between these feed documents and the feed document that people subscribe to? I think the subscription feed needs to be pinned to one end of the set (which is what FH does now). Otherwise, it becomes difficult to figure out whether you have the complete set or not by polling. I think this will be dependent on the context in which the link rels are used. The subscription link rel you've suggested is a good solution to this problem. Within any of the feeds in the set, the subscription link rel would point to the feed that should be subscribed to -- regardless of whether the subscription feed appears at the start or end of the set. On 14/10/2005, at 3:16 PM, 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 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 should be made as to whether or not the entries in those feeds share any form of ordered relationship. link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: 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 surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems _ ___ BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
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 anchored, while the 'last' end would shift as more is added. e.
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 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 useful? Separately, you say: The first may not be relevant in the Feed history case but does come into play when thinking about paged search results, sequences of linked, non-incremental feeds, etc. How? Can you give us a bit more flesh for the use case? Again, I'm not saying it's bad, but I don't see how it's useful in a feed (as opposed to a Web page). 2) What's the relationship between these feed documents and the feed document that people subscribe to? I think the subscription feed needs to be pinned to one end of the set (which is what FH does now). Otherwise, it becomes difficult to figure out whether you have the complete set or not by polling. I think this will be dependent on the context in which the link rels are used. The subscription link rel you've suggested is a good solution to this problem. Within any of the feeds in the set, the subscription link rel would point to the feed that should be subscribed to -- regardless of whether the subscription feed appears at the start or end of the set. What would the algorithm be for assuring that you have the complete state of the feed, without necessitating traversal of the entire feed every time? Cheers, -- Mark Nottingham http://www.mnot.net/
RE: Feed History -04
I was wondering if someone might be able to summarize the issues associated with a link rel=next and link rel=previous? What were the primary objections? I ask because it seems like a very logical core component for the spec, especially as a link relation. -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 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 generally useful across a broad variety of feed application cases. Regardless, it would be very good to see these registered. - James James Holderness wrote: 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. Does that mean they've actually started some kind of registration process or they're just hoping to do so at some point in the future? Another issue worth noting is that their example RSS feed is also using atom:link to provide this functionality. Robert Sayre wrote: No, but Amazon OpenSearch has been threatening to register it, FWIW. :)
Re: Feed History -04
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 provides a solution to paging in the protocol and are generally useful across a broad variety of feed application cases. Regardless, it would be very good to see these registered. +1 -joe -- Joe Gregoriohttp://bitworking.org
RE: Feed History -04
+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 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 generally useful across a broad variety of feed application cases. Regardless, it would be very good to see these registered. - James
Re: Feed History -04
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 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 generally useful across a broad variety of feed application cases. Regardless, it would be very good to see these registered. - James James Holderness wrote: 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. Does that mean they've actually started some kind of registration process or they're just hoping to do so at some point in the future? Another issue worth noting is that their example RSS feed is also using atom:link to provide this functionality. Robert Sayre wrote: No, but Amazon OpenSearch has been threatening to register it, FWIW. :) -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems -- Mark Nottingham http://www.mnot.net/
Re: Feed History -04
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 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 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 generally useful across a broad variety of feed application cases. Regardless, it would be very good to see these registered. - James James Holderness wrote: 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. Does that mean they've actually started some kind of registration process or they're just hoping to do so at some point in the future? Another issue worth noting is that their example RSS feed is also using atom:link to provide this functionality. Robert Sayre wrote: No, but Amazon OpenSearch has been threatening to register it, FWIW. :) -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems -- Mark Nottingham http://www.mnot.net/
Re: Feed History -04
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 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. e.
Re: Feed History -04
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 (next/previous/first/last). 'first' or 'start'? 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, that's a good question. Maybe calling them top and bottom would work better. Considering that the convention is to put the newest entry at the top of a feed document, top might be more intuitively understandable as being the new end. You might also rename next and previous (or is it previous and next?) to down and up. There's SOME chance of that getting confused with hierarchical levels, but I could live with that.
Re: Feed History -04
* 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, that's a good question. Maybe calling them top and bottom would work better. Considering that the convention is to put the newest entry at the top of a feed document, top might be more intuitively understandable as being the new end. You might also rename next and previous (or is it previous and next?) to down and up. There's SOME chance of that getting confused with hierarchical levels, but I could live with that. 'inaugural' and 'latest'? :-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed History -04
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 (next/previous/first/last). 'first' or 'start'? 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. Eric, It's like deja-vu all over again. http://bitworking.org/news/Atom_Auto_Sub_How_To :) -joe -- Joe Gregoriohttp://bitworking.org
Re: Feed History -04
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 start. In the context of paging link relations (first/next/prev/last) I would've thought that 'first' and 'last' are boundaries, and only the 'last' boundary would shift over time as more is added. e.
Re: Feed History -04
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 very good candidates for the link element. I never raised my voice against the move at the time because I assumed most decisions on this list were good ones. There is one reference to prev and next here: http://www.intertwingly.net/wiki/pie/LinkTagMeaning Henry On 9 Oct 2005, at 10:47, Henry Story wrote: I believe it was part of atom 0.3, and for some complex reason I never bothered trying to understand someone decided it should be moved over to the protocol side of things. Probably just because the debate was taking up too much time... So yes. 'prev' and 'next' have always been intended to be there in the link element... Henry On 9 Oct 2005, at 10:39, James Holderness wrote: Following up on the idea of using atom:link instead of fh:prev, I recently came across an old article by Mark Pilgrim on XML.com (http://www.xml.com/pub/a/2004/06/16/dive.html) in which he discusses the atom:link element and the various rel attributes it supports. He specifically brings up the issue of feed history and using next and prev to link archives together. It sounded to me as if he was talking about an existing feature in the spec - it wasn't like he was proposing it as a new idea. So was this something that used to be part of an old version of the spec that was later removed? Or was this an early proposal that was never accepted into the spec? Also of interest: there's a link from that article to his archives on diveintomark.org which actually include next and prev links in the feed. I'm almost inclined to add support for that just so I can access those old posts. There used to be some excellent articles on his site.
Re: Feed History -04
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 the rel attribute must be one of the values enumerated in the API specification. And at the time the API specification included (amongst others) start, next and prev. They were only recently removed (in draft-ietf-atompub-protocol-03). If you look at the draft prior to that you'll find them in section 3.5.1. Regards James Henry Story wrote: 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.
Re: Feed History -04
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 http://www.intertwingly.net/wiki/pie/PaceFeedState), so we removed that section (earlier this year, IIRC). On 09/10/2005, at 1:39 AM, James Holderness wrote: Following up on the idea of using atom:link instead of fh:prev, I recently came across an old article by Mark Pilgrim on XML.com (http://www.xml.com/pub/a/2004/06/16/dive.html) in which he discusses the atom:link element and the various rel attributes it supports. He specifically brings up the issue of feed history and using next and prev to link archives together. It sounded to me as if he was talking about an existing feature in the spec - it wasn't like he was proposing it as a new idea. So was this something that used to be part of an old version of the spec that was later removed? Or was this an early proposal that was never accepted into the spec? Also of interest: there's a link from that article to his archives on diveintomark.org which actually include next and prev links in the feed. I'm almost inclined to add support for that just so I can access those old posts. There used to be some excellent articles on his site. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems -- Mark Nottingham http://www.mnot.net/
Re: Feed History -04
On 10/9/05, Henry Story [EMAIL PROTECTED] wrote: 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. 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
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. No, but Amazon OpenSearch has been threatening to register it, FWIW. :) Robert Sayre
Re: Feed History -04
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. Does that mean they've actually started some kind of registration process or they're just hoping to do so at some point in the future? Another issue worth noting is that their example RSS feed is also using atom:link to provide this functionality. Robert Sayre wrote: No, but Amazon OpenSearch has been threatening to register it, FWIW. :)
Re: Feed History -04
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 registration. Does that mean they've actually started some kind of registration process or they're just hoping to do so at some point in the future? -- Mark Nottingham http://www.mnot.net/
Re: Feed History -04
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 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 registration. Does that mean they've actually started some kind of registration process or they're just hoping to do so at some point in the future? -- Mark Nottingham http://www.mnot.net/
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 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 generally useful across a broad variety of feed application cases. Regardless, it would be very good to see these registered. - James James Holderness wrote: 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. Does that mean they've actually started some kind of registration process or they're just hoping to do so at some point in the future? Another issue worth noting is that their example RSS feed is also using atom:link to provide this functionality. Robert Sayre wrote: No, but Amazon OpenSearch has been threatening to register it, FWIW. :)
Re: Feed History -04
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 to do it as an Individual submission). At first I thought this was a good idea, but I'm starting to have second thoughts. The spec as it stands is fine for RSS 2, but I can see a lot of Atom people thinking that you should be using atom:link (as Henry suggested) and not wanting to corrupt their nice new format. No doubt the RSS 1 folks have their own preference for where this should be going and will probably be even more adamant that you do things the correct way (not sure what that might be - something using dc:relation maybe?) I would worry that if they don't like it, they won't use it. I think the RSS 1.0 folks would be happiest with a self-contained extension in its own namespace with each term having clear unambiguous semantics. I think Mark's design achieves this. Ian -- http://internetalchemy.org | http://purl.org/NET/iand Working on... Silkworm http://silkworm.talis.com/
