In practice, "self" could be one of 10 URLs. Most CMSes out there will return self equal to whatever URL you happen to come across the feed. A great example is Google Reader Shared Items. Here's my feed, and it's variants. Each one is essentially the same feed, but with small differences in the URL:
http://www.google.com/reader/public/atom/user%2F10577182142674084604%2Fstate%2Fcom.google%2Fbroadcast http://www.google.com/reader/public/atom/user%2F10577182142674084604%2Fstate%2Fcom.google%2Fbroadcast?ann=true http://www.google.co.jp/reader/public/atom/user%2F10577182142674084604%2Fstate%2Fcom.google%2Fbroadcast?ann=true http://www.google.co.uk/reader/public/atom/user%2F10577182142674084604%2Fstate%2Fcom.google%2Fbroadcast?ann=false ... It gets worse, considering Google has 100+ country-specific domains. So my point is, in the wild, in practice, nobody uses "self" correctly. We're setting ourselves up for failure if we expect publishers and subscribers alike to properly serve and follow "self" links. Resolving the atom:ids (which are the same for all of the feeds above) seems to work a lot better in practice. Does that make sense? On Mon, Oct 19, 2009 at 5:49 PM, Tim Bray <[email protected]> wrote: > > On Mon, Oct 19, 2009 at 1:30 PM, Brett Slatkin <[email protected]> wrote: >> >> I'm doing this same "anti-aliasing" of feed URLs by using >> //atom:feed/id elements. The "self" link (which is in the 0.2 spec) >> doesn't work right in practice, methinks. Not sure how well we'll >> define this for 0.3 though. > > Really? I thought the requirement to use the 'self' link was smart, > precisely for the reason given in the spec. What's the problem? -Tim >
