Cart
[Home] [By Thread] [By Date] [Recent Entries]
Like Tim Bray, after I read enough of this I wonder whether I am missing some circuit in my brain, though I am untroubled by somewhat different concerns than is Tim, viz.: I embraced the internetwork architecture because the roles and functions of the constituent nodes were limited and explicit, and the URL scheme curtailed the scope of assumptions or axioms which would otherwise be incompatible with my own processing requirements. In the internetwork architecture servers return entity bodies--bits on the wire--which inevitably carry formatting or presentation bespeaking the assumptions or intent of those who design and manage the content of a server. The URL scheme, in making explicit that those bits pass from one domain into another, also makes clear why I don't have to care about those assumptions, nor respect the presentational manifestation which they assume: the scope of the server's intent is limited, if not more severely, then at the least to the boundary of its domain name. There are means other than http by which an equivalent entity body might be conveyed--not just to me but to a host of recipients, interested for their own idiosyncratic reasons: email, instant messaging, diskettes delivered by sneakernet all deliver bits processable by software into a domain--and into a domain of assumptions and expectations--differing from the domain where the content was created. The internetwork architecture must assure that the bits survive the journey intact, but it also indicates why the assumptions should not: they manifestly belong to a different domain, in a domain naming scheme particularly suited to making the boundaries of local assumption and the scope of local intent. To process whatever of use might be available in the bits I receive, I must first instantiate a data structure particularly suited to my own processing. It would be as foolish for me to assume that the bits I receive are noticeably related to the form in which I must instantiate data for my own use as it would be for the creator and publisher of those bits to assume that I should follow the, to me, accidental form of their format or presentation in my independent instantiation of my own data. The great service which the creator and publisher have done me is in publishing data. They may limit access to that data to only the smallest audience of those who can demonstrate appropriate authorization, but they have still published the data. 'Publish' here means that they have made the data available without reference (or much thought) to the form in which I might require it. The content published is an expression of its creator's expertise, including in the form of its presentation an inevitable manifestation of the creator's point of view. It is not private-use material specifically intended for my particular instantiation and subsequent use of it. The domain name at which such data is published stamps the published form of data (and every retrieval of it, which must address that name) with the scope and boundary of the assumptions, the axioms and the intent which that data might reasonably convey. It is, ironically perhaps, by imposing these explicit boundaries on every inter-node transaction that the internetwork achieves universal scale. There is no center to limit the foederal scalability of the internetwork, not even the center of an original form of content, from which every use and re-use might be imagined as on ripples radiating outward. It is the task of a sufficiently capable server to negotiate content and return a well-chosen representation--a particular entity body of bits on the wire. The server offers a selection of various presentations of particular data, but from that we must not infer some platonic form of which those choices are the instance manifestations. It is an accident of labelling within the URL scheme that those forms appear to have some underlying identity--or, perhaps better, it is an assertion from that server through URL labelling that there is some commonality in those manifestations. That does not establish any meaningful identity or even similarity of data, outside of URL labelling, even at the server, let alone any commonality which should be respected by a client explicitly in a different URL domain and with different understanding of and uses for that data. Functionally, the relationship of URIs to things--at least those things which are comprehended by software, which is to say processable data structures--is necessarily many-to-many. This is a chief feature of the URL naming scheme. Through URL labelling many manifestations of data may be marked with the same name and the functional question left to the server of which entity body to return in response to a particular request. Once safely transported to the node which acted as client in that request, the entity body transmitted is not the entity body required; it is only an ephemeral intermediate form preceding the data structure which that node actually requires and must instantiate before doing any useful processing. Where 'things' are the things that software comprehends, the nature of processing those things by addressing them through URLs necessarily places them in a many-to-many relationship. The only way to unify the many physical manifestations which might be labelled with a given URL is to assert that out of that identity of naming we create some actual identity or some platonic form of which all the physical instances are manifestations. But at the functional level of the working internetwork topology, many data structures share an accidental identity of naming in a URL at which they are addressed for retrieval on the way to instantiation in varying forms. Respectfully, Walter Perry
|
