The new architecture was being created for the workers. The holiest of all goals: perfect worker housing. - Tom Wolfe
The thread that wouldn't die.
Tim Bray disagrees with Mark Pilgrim around URIs as identifiers.
Marks' position, which is fairly specific to Atom:
- Permalinks are transient, not permanent.
- Keep permalinks and ids distinct.
- Prefer tag: URI constructs for ids.
Tim's position, which strays beyond Atom:
- Get decent software that generates context free URIs.
- Permanently own a domain.
- Don't use tag: URIs because they're not registered (but don't think hard about why that is).
- Any identity model that isn't single URI (nominalist) is Web-unfriendly (specifically, you'll burn bookmarks, Pagerank and caches)
On the face of things, this is very sensible advice, and is essentially the core W3C dogma - cool URIs don't change. But there are some details that happens to strengthen Mark's position and weaken Tim's. In short - forget about the application software; the Web/Internet infrastructure itself doesn't support cool URIs.
Never mind the URI, here's my UUID.
If you think that there's a good chance your URIs will change, you shouldn't use them for IDs. But, if you think that, you should also bloody well be looking for better software or hosting or whatever.
Let's talk about ICANN instead. We can bang on all day about getting tooled up with decent software to generate sensible URIs and not harm Pagerank, but that is to neglect issues around domain name ownership, which cannot be solved in software. The dirty secret of the Web is that you don't own your domain name; you rent it. As soon as you stop renting it, every URI under that namespace is almost certainly toast, irrespective of whether someone else rents it after you. What kind of permanence is that? No-one will support your ex-URI space because it cost money to serve up content on the web and the more read you are (or were) the more it costs. No amount of non-broken software will not help you here. But an id tag can. Having said all that, here's my (strawman) counter-argument :
If you think that there's a good chance your URIs will change, you shouldn't use them for IDs. But, if you think that, you should also bloody well be looking for better domain name governance or perpetual rights to domain names or a more democratic web or a web that doesn't punish content providers or whatever.
Arguing for permanance in http: URIs when the critical partition of the http: namespace, the domain, is de facto transient - make what you will of it.
I dislike Mark Pilgrim's position, because it involves managing the relationships between various identifiers, which can get complicated, is prone to inconsistencies, and is invariably a local solution (whereas using a lone URI is not). I think it helps to have to had to deal with or integrate namespaces where names/identities are composite entities like Atom's to appreciate what a compelling idea the lone URI is - folks, there's real money down in managing composite identities across administrations. Consequently the Atom id tag sucks. However, Mark's position does address issues with URI (ie, domain) transience. Consequently the Atom id tag sucks, but I will end up using it.
Emotionally, I like where Tim's coming from much better, but emotionally I like world peace much better too. Short of radically different web infrastructure and management, Mark's way will work out for most folks, who are not and never will be web geeks, administrators, or information architects. The "Cool URIs don't change" argument doesn't work so well unless you are in position to guarantee perpeptuity, or have a deep and strong technical understanding of web architecture - the evidence suggests it doesn't work at all at the "consumer grade", which is most bloggers. Otherwise - in my case that means roughly 150 euros a year (well worth it) and nobody trading on the name "dehora" coming to boot me out of that domain (we'll see about that being worth it). But it's my job to know about this stuff; I'm not a consumer grade exemplar.
I don't know - sometimes the cool URI view seems to belong in a Carlsberg advertisement, who don't do web architecture, but if they did it'd probably be the best web architecture in the world: power is decentralized to the edge peers, people own their domain names, they can affordably serve content, they can host their own content, they can continue to do so when the world loves to read their content, they can avail of sensibly crafted software so they don't have to be programmers if they don't want to be, they don't get hounded out the domains, bodies like ICANN and the IETF are running like well-oiled machines, and the physical architecture supports what the web and information architects want. The web we have is not like this - it is natted, centralized, dynamically assigned, firewalled, attacked, mismanaged, inefficient, litigated over, awash in expediency, filth, greed and infection. The Web is much more like the real world than the Web.
Death and taxes.
The deployed Web works against cool URIs, not for them. That's what Mark Pilgrim understands and the W3C does not. To publish cool URIs is to actively enage in a fight against entropy, the natural order of things.
'Permalink changes'? Yes, permalinks are not as permanent as you might think. Here's an example that happened to me. My permalink URLs were automatically generated from the title of my entry, but then I updated an entry and changed the title. Guess what, the 'permanent' link just changed! If you're clever, you can use an HTTP redirect to redirect visitors from the old permalink to the new one (and I did). But you can't redirect an ID.
I don't have a problem using titles in Atom permalinks, or with using tag: URIs in Atom ids. I've come to decide that I won't change titles post publication. As for tag: URIs - I happen to be a fan of these. Despite whatever problems Tim has reading them, I find them easy enough to eyeball. It takes 15 minutes to implement a generator. The fact the scheme is not registered doesn't matter because the reason it's not is not a technical/engineering matter; it's down to an obtuse registration process. Again this is an issue that goes beyond software and comes down to management. So I say go ahead and use tag: URIs for Atom ids.
Despite all that I'm up for following Tim's line; I will continue dole out per annum to rent and host dehora.net for as long as I can afford it. I am careful about issuing permanent URIs, but definitely not careful enough - for example I've had to port most of the URIs for this weblog, since MT does not do out of the box what web 'nominalists' consider the right thing. I've left behind redirects as Mark describes above. The conclusion? As things stand it's unrealistic to expect more than a small minority to do likewise or to really care about stable identifiers. There are better things to be doing that agonizing over URIs and the lifespan of a domain name. That anyone has to is a failure of the architecture as deployed.
[limp bizkit: faith]
first published: 2004-05-29 17:05:33. Some edits have been made and typos fixed, but the reason that the date was changed (aka 'genxed') is that the ID/URI permathread has come up on the Atom working group list recently, and for anyone involved who reads here, this post captures my essential position on the matter, which is probably best understood as one of realpolitik.