Original sin and the ruin of HTTP URIs

HttpRange-14, the endless nightmare conversation that has pretty much redefined "rathole", has opened its gates again as another brave explorer attempts to put it finally to rest. Everyone who's gone anywhere near it knows it isn't comfortably settled, and I suspect those of us who've gone close to it will never forget the sound of its rattling around and moaning.

How did we summon this demon, and why do we keep it around?

Its origins are deep and dark. I first encountered this original sin of the Web in the days of XML namespace controversies, around the time when XML namespace controversies blew the lid off W3C URI dysfunction, and the resulting xml-uri explosion. That was where I first discovered there were people - the Director of the W3C and his right hand man no less - who thought it perfectly fine to create URIs that did nothing but sit there looking pretty, with some theoretical "it means something else" hanging off the side. Worse, the Pope, his Bishop, and friends enjoyed abusing the fragment identifier portion of the URI to mean something other than fragment identifier, and in so doing popularized one of the nastier anti-patterns of modern web development.

So what's the basic problem?

Once upon time, probably in the simpler age of URLs - Uniform Resource Locators rather than the more recent URIs (Uniform Resource Identifiers) - if you saw something that started with http:// you knew it was a pointer to a web resource. To figure out what it wanted to share with you, you dropped it into a tool, typically a browser, that understood the HTTP protocol, and it would go retrieve something from that location.

URIs, in theory at least, combined URLs with the more opaque Uniform Resource Name, allowing both to be used in a variety of contexts. Unfortunately, in practice, the opacity of URNs and their lack of a clear path to particular resources somehow was confused with virtue. Worse, that opacity was applied to URIs that happened to take the http:// form, leading to bizarre trainwrecks like the recommendation that XML namespace URIs not point to anything even if they happened to use http:// (as was generally recommended...).

The good news about this particular form of sin is that so far it has been confined to a relatively small number of practitioners, perhaps best described as theologians of the Web. XML developers learned quickly that any conversation about universal handling of namespace URIs would land them in perdition, and despite the good work of RDDL, basically stopped talking about it except as a parlor game. Semantic Web practitioners are the most eager evangelists of this heresy, but while they are starting to achieve critical mass in solving problems, the community itself remains small and the collections of broken URIs they produce rarely find their way into daylight.

Unfortunately, it seems likely that as the Semantic Web finally achieves critical mass, the rumbling will get louder. Humans may be spending less and less time in direct contact with http:// URIs, but they (and HTTP itself) are at the foundation of REST-based systems. We'll just have to hope that none of the abused http:// URIs fall into the hands of REST-based systems that expect them to have a relationship to resources on the HTTP-based Web.

Update: Somehow I managed not to link the post that triggered this, and you can also find other comments on it.