Re: New Link Relations -- Last Call
I've had a response; they're happy (Joe G can confirm this), and say they'll update their next draft to accommodate the regs. All systems go; requesting registration shortly. On 03/11/2005, at 6:54 AM, Mark Nottingham wrote: On 24/10/2005, at 2:12 PM, Peter Robinson wrote: That is true, but have you communicated with the OpenSearch people about this? I do strongly believe that *here* is the place for work like this, rather than behind closed doors at Amazon. But if I was them I'd feel pretty miffed that this WG appears to have basically stolen their idea in a desperate 'land grab', and turned it on its head so that it is (arguably) the complete opposite of their intended definition. The only place to give them feedback is on a Web form. I've submitted feedback and will wait to see if there's any response. -- Mark Nottingham http://www.mnot.net/
Re: New Link Relations -- Last Call
On 24/10/2005, at 2:12 PM, Peter Robinson wrote:That is true, but have you communicated with the OpenSearch people aboutthis? I do strongly believe that *here* is the place for work likethis, rather than behind closed doors at Amazon. But if I was them I'dfeel pretty miffed that this WG appears to have basically stolen theiridea in a desperate 'land grab', and turned it on its head so that it is(arguably) the complete opposite of their intended definition.The only place to give them feedback is on a Web form. I've submitted feedback and will wait to see if there's any response.Cheers,--Mark Nottingham http://www.mnot.net/
Re: New Link Relations -- Last Call
Am 23.10.2005 um 23:34 schrieb Mark Nottingham: On 23/10/2005, at 1:04 PM, Peter Robinson wrote: I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas you say you can live with 'current'. So, at this point it looks like 'current', unless other people come forward. I flirted with recent briefly; anybody strongly like that one? Maybe it is clear to everyone but me...however i do not see the damage done by using rel=self instead of inventing a new relation. Could someone bother to explain that? I know the definition in the format spec says it points to an equivalent resource, but it also says that This is the preferred URI for retrieving Atom Feed Documents representing this Atom feed. I probably do miss something important here, but a) equivalent resource says either nothing or lets you enter a mine field while roy t. machine guns you b) representing this Atom feed requires some king of dualistic thinking: the whole Atom feed is composed of several Atom feed documents which are linked with prev and (maybe) next relations. self points to the URI for the overall feed and has the same value in all chained feed documents (or feed chunks as i would call them) Can I convince anyone to enter the land where an Atom feed is composed of one or more Atom feed documents? Cheers, Stefan
Re: New Link Relations -- Last Call
I agree self would do well. But it is true that it's current definition is a little vague. I don't suppose one can refine it in a way consistent with its current definition? In any case this all looks good to me. As soon as we agree on the names, I will implement these links in BlogEd, so that the web server can keep a complete history of published changes. What would I need to add to my feed to make it clear that I my feed is incremental (I think that's what my feed would be)? Henry On 24 Oct 2005, at 10:37, Stefan Eissing wrote: Am 23.10.2005 um 23:34 schrieb Mark Nottingham: On 23/10/2005, at 1:04 PM, Peter Robinson wrote: I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas you say you can live with 'current'. So, at this point it looks like 'current', unless other people come forward. I flirted with recent briefly; anybody strongly like that one? Maybe it is clear to everyone but me...however i do not see the damage done by using rel=self instead of inventing a new relation. Could someone bother to explain that? I know the definition in the format spec says it points to an equivalent resource, but it also says that This is the preferred URI for retrieving Atom Feed Documents representing this Atom feed. I probably do miss something important here, but a) equivalent resource says either nothing or lets you enter a mine field while roy t. machine guns you b) representing this Atom feed requires some king of dualistic thinking: the whole Atom feed is composed of several Atom feed documents which are linked with prev and (maybe) next relations. self points to the URI for the overall feed and has the same value in all chained feed documents (or feed chunks as i would call them) Can I convince anyone to enter the land where an Atom feed is composed of one or more Atom feed documents? Cheers, Stefan
Re: New Link Relations -- Last Call
* Henry Story [EMAIL PROTECTED] [2005-10-24 12:00]: What would I need to add to my feed to make it clear that I my feed is incremental (I think that's what my feed would be)? By my understanding, incremental is the default semantic for a feed, so to make it clear that that’s what yours is you would add nothing. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New Link Relations -- Last Call
Hi Mark, Mark Nottingham [EMAIL PROTECTED] wrote: On 23/10/2005, at 1:04 PM, Peter Robinson wrote: I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas you say you can live with 'current'. I can. The argument as I understand it is that relations should be nouns rather than verbs (describing what the link points to rather than what you should do with it). I can't argue that point, but I do feel that 'current' less encapsulates the intent than 'subscribe'. Someone else suggested 'subscription'. This should be my last word on the subject: Apparently it came as a surpise to some that rel='self' as defined is not the same as 'the url you should subscribe to' in the general case. I don't want to make the same mistake yet again. First example: consider a statically archived non-incremental OpenSearch-style feed split into pages: http://www.example.com/feed/2001/page3 A reasonable interpretation (the only possible interpretation?) of rel='current' would be this: http://www.example.com/feed/current/page3 which is certainly not the url you should subscribe to. Second example: a dynamic feed where cgi variables are used to set options, perhaps for use in building an html page of links rather than normal subscription, but you can come up with other uses: http://www.example.com/feed?year=2001no_atomcontent=yes Rel='current' would point to http://www.example.com/feed?no_atomcontent=yes but it would be much better for PubSub or a desktop aggregator to go to http://www.example.com/feed if it ever got hold of such a feed. The second example is (essentially) something I already do. I don't expect urls like that to 'escape' into the wild, but I can't prevent it and I'd like to be able to give an aggregator something meaningful to do when it does happen. If we want to define a link relation meaning 'the url you should subscribe to' then that is what we should define. So, at this point it looks like 'current', unless other people come forward. I flirted with recent briefly; anybody strongly like that one? I don't think that is any better. I am also worried that this is being pushed through too quickly. I appreciate that, but it's a bit of a chicken-and-egg problem; we won't get all of the implementation experience until it's defined and widely deployed. That is true, but have you communicated with the OpenSearch people about this? I do strongly believe that *here* is the place for work like this, rather than behind closed doors at Amazon. But if I was them I'd feel pretty miffed that this WG appears to have basically stolen their idea in a desperate 'land grab', and turned it on its head so that it is (arguably) the complete opposite of their intended definition. [snips] OpenSearch uses 'next' to go from page=1 to page=2. The natural paging setup for an inremental feed that is also an OpenSearch results feed is to have rel=current (aka rel=subscribe) point to the first page of results (i.e. page=1). Is it the intention that history reconstruction uses 'next' links to go back into the past? [...] Right now, the plan forward seems to be that 'next' et al will be purposefully generic; i.e., they won't mean much until used in conjunction with another extension (in my case, fh:incremental). My plan for feed history is to recommend people walk both 'previous' and 'next' from the subscription feed, so that it doesn't matter which way the feed goes. I see! That little nugget of an idea makes me feel a lot more comfortable about prev/next. So something that understands rel=previous, next et al will be able to reconstruct a complete logical feed, and the history extension will tell it 'which way is up' and whether it's a traditional 'incremental' feed. That makes a lot of sense. Regards, Peter
Re: New Link Relations -- Last Call
Mark Nottingham [EMAIL PROTECTED] wrote: I've replaced subscribe with current; otherwise, these are the same as in the last round. I think they're ready to go -- any more comments? I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. I am also worried that this is being pushed through too quickly. - Attribute Value: previous - Description: A URI that refers to the immediately preceding document in a series of documents. - Attribute Value: next - Attribute Value: first - Attribute Value: last - Description: [consequent descriptions] OpenSearch uses 'next' to go from page=1 to page=2. The natural paging setup for an inremental feed that is also an OpenSearch results feed is to have rel=current (aka rel=subscribe) point to the first page of results (i.e. page=1). Is it the intention that history reconstruction uses 'next' links to go back into the past? If so I think that must be made much more explicit in the descriptions, since it is not the natural interpretation if you come at this purely from the standpoint of blog history. On the other hand, if that is *not* the intention then paging for history and paging for OpenSearch will be incompatible. Regards, Peter -- Peter Robinson http://www.ticketswitch.com/ Concerts, sport and theatre tickets
Re: New Link Relations -- Last Call
Mark Nottingham wrote: I've replaced subscribe with current; otherwise, these are the same as in the last round. I think they're ready to go -- any more comments? +1 on everything
Re: New Link Relations -- Last Call
* Mark Nottingham [EMAIL PROTECTED] [2005-10-23 23:40]: Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas you say you can live with 'current'. So, at this point it looks like 'current', unless other people come forward. I flirted with recent briefly; anybody strongly like that one? I like “recent” better than “current,” and I agree with Tim on “subscribe.” But neither of the alternatives seems like a great fit. I thought about it for a while and came up with “live.” It would seem to me that it describes the link target with a qualtatively stronger assertion than either “current” or “recent,” and that it is more likely to intuitively convey what it’s supposed to mean, ie “if you want to subscribe to something, this link is the best candidate.” But ultimately I’m okay with any of the non-“subscribe” propositions. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
New Link Relations -- Last Call
I've replaced subscribe with current; otherwise, these are the same as in the last round. I think they're ready to go -- any more comments? - Attribute Value: previous - Description: A URI that refers to the immediately preceding document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: next - Description: A URI that refers to the immediately following document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: first - Description: A URI that refers to the furthest preceding document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: last - Description: A URI that refers to the furthest following document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: current - Description: A URI that, when dereferenced, returns a feed document containing the most recent entries in the feed. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). -- Mark Nottingham http://www.mnot.net/
Re: New Link Relations -- Last Call
What's the difference between current and last? Elias On 10/22/05, Mark Nottingham [EMAIL PROTECTED] wrote: I've replaced subscribe with current; otherwise, these are the same as in the last round. I think they're ready to go -- any more comments? - Attribute Value: previous - Description: A URI that refers to the immediately preceding document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: next - Description: A URI that refers to the immediately following document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: first - Description: A URI that refers to the furthest preceding document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: last - Description: A URI that refers to the furthest following document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: current - Description: A URI that, when dereferenced, returns a feed document containing the most recent entries in the feed. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). -- Mark Nottingham http://www.mnot.net/
Re: New Link Relations -- Last Call
cool. +1 then. On 10/22/05, Mark Nottingham [EMAIL PROTECTED] wrote: When you dereference current, you'll always get a feed document that contains the most recent entries in the feed. There's effectively a guarantee that the latest entries will be there. When you dereference last, you'll get a feed document containing the furthest following document in a set of documents. The nature of the set and its members is undefined -- it could be the last feed document, but it could also be the last entry document, and the set could be search results, archives, or anything else. There isn't a guarantee it'll always have the latest entries in it. On 22/10/2005, at 11:01 AM, Elias Torres wrote: What's the difference between current and last? Elias On 10/22/05, Mark Nottingham [EMAIL PROTECTED] wrote: I've replaced subscribe with current; otherwise, these are the same as in the last round. I think they're ready to go -- any more comments? - Attribute Value: previous - Description: A URI that refers to the immediately preceding document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: next - Description: A URI that refers to the immediately following document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: first - Description: A URI that refers to the furthest preceding document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: last - Description: A URI that refers to the furthest following document in a series of documents. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references. - Attribute Value: current - Description: A URI that, when dereferenced, returns a feed document containing the most recent entries in the feed. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). -- Mark Nottingham http://www.mnot.net/ -- Mark Nottingham http://www.mnot.net/
