Re: OK, enough with atom:id

[Mark Nottingham <mnot@xxxxxxxx>]

While respecting that consensus has been determined, I'd like to 
register my views, since I missed the opportunity beforehand.

After reading the (extensive!) threads, my impression is that the use 
cases for atom:id have not been given due consideration. Namely, no-one 
has suggested that atom:id be used for anything except identifying 
whether two instances of a construct (e.g., an atom feed) refer to the 
same logical thing.

Tim did point out that URIs can and often are written on notes, 
billboards, etc. and copied down. I do not dispute this, but it does 
not follow that all URIs in all situations are exposed to people (and 
thus subject to transposition errors).

As such, we're using URIs in atom:id as pure identifiers; they're not 
used to locate anything (e.g., by network access), and they're AFAICT 
directly copied by machines when they're transposed.

If this is the case, it seems that the underlying requirements for 
atom:id are:
  - easy to compare two instances to determine if they're the same
  - easy to make globally unique

URIs fit the bill nicely.

However, as far as comparison goes, I don't see any reason to add the 
extra machinery of URI canonicalisation. Doing so adds complexity to 
the specification and implementations, and introduces a lot of 
scheme-specific logic. Comparing atom:id as a sequence of characters is 
much cheaper and simpler.

One concern raised about this approach was that implementations that 
use XML Schema (e.g., Java, C#) would have trouble because they 
automagically normalise URIs. In fact, I think this is an argument 
against using canonical URIs, because those implementations' 
interpretation of URI canonicalisation may not be the same as Atom's, 
and may diverge over time.

Instead, the XML Schema type of atom:id should be xs:string, and its 
value should be restricted to a URI -- any URI -- by specification 
prose.

Please note that I'm not saying that the current approach won't work -- 
it will. My objection is that this adds needless complexity to the Atom 
specification without corresponding benefit, and that it will make some 
feeds needlessly invalid.

If there were use cases where transposition errors of atom:id are 
likely, I'd be much more amenable to this proposal, but I haven't seen 
that discussion.

Thanks for listening,


On Aug 5, 2004, at 11:00 AM, Tim Bray wrote:

> The survey (http://intertwingly.net/wiki/pie/IDSurvey) is conclusive.
>
> We have consensus that atom:id will be canonical URI per 
> http://www.intertwingly.net/wiki/pie/PaceCanonicalIds
>
> We also have consensus that we need strong language in our draft that 
> atom:id must be present, globally unique, and immutable (even when an 
> entry moves from category to category or feed to feed or wherever).  
> There is plenty of good candidate language out there on the mailing 
> list and in various Paces.
>
> There is lots of room for proposing language for our drafts or an 
> implementors' guide to make atom:id work better.  There have been 
> various proposals to recommend some particular URI scheme or URN 
> namespace for Atom; so far no specific scheme/namespace has managed to 
> get anything like rough consensus.  Doesn't mean it can't happen, just 
> means it hasn't yet.
>
> To our editors: please feel free to go ahead and roll in the consensus 
> language.
> Sam, there might be a few Paces on the issues list that can now be 
> closed?  -Tim

--
Mark Nottingham     http://www.mnot.net/