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: Atom Comments Extension
I believe that's because they're not necessarily expected to be derived from Atom Entry IDs. Agreed. I've been making experimental use of the extension with RSS, and will continue to do so... no Atom IDs in sight. -- Roger Benningfield
Re: Atom Comments Extension
* Justin Fletcher [EMAIL PROTECTED] [2005-10-14 23:00]: If any additional wording is necessary, then it should be explicit that it only relates to the media type of 'application/atom+xml'. It is, in my opinion, redundant to say this because ID reference for a application/atom+xml document is the Atom Entry ID. Other media types would use their own forms of identifiers. Well yes, you’re right. But I’d really want to see at least *some* explicit mention of using Atom IDs as idrefs somewhere in the spec. However redundant it may seem, I’d feel more comfortable if it wasn’t merely implied. F.ex., say you’re replying to one of Tim’s ongoing entries. This means @idref will be a HTTP URI. If someone views source and concludes he should put the permalink in there, what would you tell them? It works with Tim’s feed and there’s nothing in the spec which says what they’re doing is wrong either. But if consumers expect entry IDs in there, it will fail if they start replying to feeds using some other form of URI for their IDs. This clearly is an interoperability issue. In fact, now that I think about it, it seems that recognising that this extension should be applicable beyond Atom doesn’t mean it should be less explicit about what to use for identifiers, but rather should be more so: it should explicitly mention what should be used as an identifiert when replying to items from RSS feeds as well. (Eg. use the GUID as an idref when available, otherwise use the permalink as a href.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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: Atom Comments Extension
A. Pagaltzis wrote: * Justin Fletcher [EMAIL PROTECTED] [2005-10-14 23:00]: If any additional wording is necessary, then it should be explicit that it only relates to the media type of 'application/atom+xml'. It is, in my opinion, redundant to say this because ID reference for a application/atom+xml document is the Atom Entry ID. Other media types would use their own forms of identifiers. Well yes, you’re right. But I’d really want to see at least *some* explicit mention of using Atom IDs as idrefs somewhere in the spec. However redundant it may seem, I’d feel more comfortable if it wasn’t merely implied. +1. I'll make that change This clearly is an interoperability issue. +1 - James
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/
