Re: New Link Relations? [was: Feed History -04]
On 18/10/05 3:32 PM, Mark Nottingham [EMAIL PROTECTED] wrote: Such agents should also take care to detect circular references between feeds when following them. s/between feeds when/between feed documents/ otherwise +1 e.
Re: New Link Relations? [was: Feed History -04]
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: 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: 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: 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: 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: 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/
