I Knew I Was Afraid of URIs for a Reason
Netscape validates my fear of URIs (link thanks to Dare). There are a couple issues here.
First, how does something like this affect visions of the unfolding web? On the one hand, storing the same data in two live sources (not counting backups here) is commonly taken as an inefficient and dangerous practice. If the data needs to be changed, you should only have to change it in one place (i.e. DRY). On the other hand, repeatedly pulling the exact same document down over the network seems fairly inefficient itself. Not only inefficient, but it makes the system less robust by means of requiring a network connection between two points, and taking a dependency on a data source that is potentially not under the control of the consumer application’s developer. A change in the data source could violate assumptions made by the developer, thus leading to unpredictable changes in the functionality of the application. I think we can safely say that DRY is a good practice to follow in one’s own work, but is there a distributive law of DRY? I don’t know.
Second, as a commenter to the Netscape blog post linked above mentions, if the URI were used simply as an identifier rather than an actual link to a live resource, then this would not be as big of a problem. I genuinely dislike the apparent multiplexing of URL strings, including protocol-specifying prefixes, with a usage as an abstract, unique identifier. Confusion is a direct consequence of either usage: If I use a link like http://www.arcadianvisions.com/my_format effectively as a namespace, without actually creating something like a DTD and making it accessible from that location, someone looking to find information on the format would be misled by my identifying string. Similarly, if I did store a format specification at that location, someone might take a hard dependency on it and be forever reliant on my web hosting and directory layout.
In this case the data is static, so an identifier — one that does not actually locate a resource on the web — is sufficient as long as everyone includes their own copy of the referenced data with their application. But does this violation of DRY represent the potential for disaster? If a critical flaw is found in the format, how could we respond? My personal views, at this point in time, tend towards the notion that we should be pulling the data from the net repeatedly, but that a more data-centric localization scheme is needed.
