Hi Brian, * Brian Smith <[EMAIL PROTECTED]> [2007-09-14 18:40]: > This is it will almost always result in a bad value for @ref. > Who is going to use the permalink to the HTML version of an > entry as an atom:id?
anyone who wants to. An ID can be any valid URI, and HTTP URIs are valid URIs, so they can be used as Atom IDs. Tim Bray does that: http://www.tbray.org/ongoing/ongoing.atom > In fact, if you Google for "atom:id" then the first result is > an article that goes into great detail to persuade us not to do > so (http://www.google.com/search?q=atom:id). And Tim Bray goes into great detail to persuade you that you should: http://www.tbray.org/ongoing/When/200x/2004/05/28/LinksAndGuids (I disagree with both of them on various points and have decided to use urn:uuid: IDs instead.) > In particular, if the content producer does not know of an > appropriate atom ID to use for a thr:in-reply-to/@ref > attribute, it SHOULD NOT include the attribute. The rationale was to make it likely that encourage will do their threading based on the same identifier even in cases where no Atom ID is known. > Content consumers may always substitute the value of the @href > attribute for a missing @ref if it feels like it really needs > an atom:id using the same rules that are currently imposed on > content producers. So in both cases, a reply to something which has no known Atom ID is threaded based on its URI. > If the other person was to upgrade to some Atom-enabled > weblogging software, then all his entries would have an > atom:id. But, the atom:id his weblogging software chooses > probably won't match the atom:id I made up for that resource. This is a general problem. If @ref attributes could be omitted, then then migrating from an Atom-unaware weblogging tool to an Atom-aware one, @ref attributes will continue to be missing even after Atom IDs are minted for the old entries. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
