RE: <id> and <link> are broken! (was RE: base and atom:id)

["Danny Ayers" <danny666@xxxxxxxxxxx>]

> > So I ask, why is it a fact that an entry needs these
> > two things?  Why
> > can't the ordinary old-fashioned URL also serve as
> > an identifier?  -Tim
>
> Because a URL can change and is fleeting while a
> globally unique identifier does not. Blogs move all
> the time and the URLs of entries change.

But what actual benefit is a separate GUID?

Say we have a blog post:

<guid>1234</guid>
<url>http://myolddomain.com/post1234</url>
<content>my lovely horse</content>

and the URL changes:

<guid>1234</guid>
<url>http://mynewdomain.com/post1234</url>
<content>my lovely horse</content>

The GUID can tell you that the two entries are the same *but that's all*. In
particular, it offers no way for a system to locate the new copy of the
entry. If URLs really are that fleeting, then it doesn't make a blind bit of
difference whether you use them purely as locators or not. If the post moves
then the contents of the <url> no longer points to it.

The same information as above could just as easily be encoded as:

<url>http://mynewdomain.com/post1234</url>
<sameAs>http://myolddomain.com/post1234</sameAs>
<content>my lovely horse</content>

Note that neither of these are actually saying which post is the current
one - that could easily be fixed by using instead of <sameAs>, something
like:

<replaces>http://myolddomain.com/post1234</replaces>

This approach would also conveniently be consistent with the most
authoritative architectural view of the web we've got at the moment. Whether
or not you agree with it, most of the specs we're using make assumptions
based on URIs being primarily identifiers, with the mechanism for access of
representations of the resources identified being orthogonal. Like I said
before, it'll be far easier to build Atom on what we've got than to
reinterpret the whole web architecture and rewrite specs accordingly (even
if that was a good idea).

But in any case, if you revert to the URL-oriented view, you're still
looking at an address string that identifies the location, it doesn't help
with the practical problems.

Luke blogged about a
> certain blog tool used by a popular .NET developer
> community that caused such problems for SharpReader
> (and RSS Bandit) at
> http://www.hutteman.com/weblog/2004/01/05-153.html

Yes, and what he describes is a problem encountered when using a GUID! This
could have been avoided had the change been made explicit.

The suggestion that using a GUID for <id> will somehow help with the problem
of relocated blogs is a complete red herring. The use of a separate URI for
(non-retrievable) <id> and (retrievable) <link> for a single entry resource
is an ugly kludge which has no place in a specification that's intended to
sort out problems in current practice.

I've a feeling some of the arguments coming out around this point relate
more to the reuse of RSS-oriented code for Atom support than to actual good
design. Don't let's forget that we've a change for a fresh start here, we
should concentrate on getting things right, rather than writing the spec to
fit existing implementations.

Cheers,
Danny.