- From: Miles Sabin <miles@milessabin.com>
- Date: Thu, 1 Aug 2002 11:09:54 +0100
- To: "www-tag" <www-tag@w3.org>
Roy T. Fielding wrote, > An http URI, when it is dereferenced, activates a mechanism whereby > the string of characters in the URI is used to select a bag of bits > that is supposed to represent the state of the abstract thing > identified as a resource via the http naming authority. I think this very clear statement points to the crux of my disagreement with Roy's position. I would agree to the following, An http URI, when it is dereferenced in the way characteristic of the HTTP protocol, activates a mechanism whereby the string of characters in the URI is used to select a bag of bits that is supposed to represent the state of the abstract thing identified as a resource via the http naming authority. In fact, I'd go further and say that this looks very promising as a _definition_ of "dereference" within a framework which incorporates the HTTP protocol, http URIs and a particular conception of resource ... I guess that framework is REST. Where I differ is that I don't accept that this conception of resource and dereferencing is the only one ... I'm not even sure that it's the one most commonly associated with http URIs. Some examples of alternatives, * (One Roy gave elsewhere in his post) Auto manufacturers might agree to stamp every vehicle with a unique http URI. We might "dereference" such a URI by physically pointing at the vehicle, or a car park attendant might drive it somewhere accessible to its owner. * XML namespaces are abstract, stateless, pointlike entities, which have no defining characteristics other than being numerically distinct from one another. The http URIs used to identify them are "dereferenced" in the course of namespace processing in an XML processor, merely by being used to demarcate the scope of XML names. * It's common practice to treat cannonical "entry point" URIs (eg. http://www.w3.org/) as identifiers of complete web-sites. These http URIs might be "dereferenced" by REST-dereferencing one or more URIs (not necessarily including the entry-point URI itself) identifying REST-resources which are parts of that web-site, or informally (eg. "Where's the RDF spec? It's on http://www.w3.org/.") * It's common for http URIs to be subject to multiple informal interpretations (eg. http://www.w3.org/ might, in appropriate contexts, be used to refer to a bag'o'bits, an HTML document, the W3C's website, the W3C, the best example of accessible web page design, Joe Blogg's favourite web site, my favourite example when waffling about URIs etc. etc.). Exactly what constitutes "dereferencing" in these contexts is liable to be as variable as the contexts themselves. Is there any uniform conception of resource and dereferencing at work here? In a sense, I think yes ... but only a schematic one. In each case we have a trio of, * A practice/mechanism: REST; car parking; namespace processing; talking about web sites; the general incorporation of URIs into natural language. * An http URI used within that practice/mechanism: HTTP GET; fetching the car; distinguishing XML names; natural language conversation about web-sites or whatever. * Zero or more referents as identified by the URI within the practice/mechanism: a REST resource; a car; an abstract namespace; a web-site; anything else determined by a particular conversational context. Depending on the practice/mechanism in play, the URI might or might not be unambiguous, or guaranteed to exist. If you match these up in the right way and there's no doubt about which practice is in operation, then there's really no problem at all. OTOH, if you try and ignore the role played by the relativization to a practice we'll end up with absurdities like HTTP GETs of cars or attempts to identify abstract namespaces with associated documents. So my objection isn't to REST/HTTP GET/resource, it's only to any suggestion that that particular trio is in any way special or fundamental when it comes to saying what an http URI denotes. It's pretty clearly fundamental when GET is involved, but GET isn't the only thing that can be (and _is_, in practice) done with an http URI. If REST were the be all and end all of Web Architecture, then I think we could wrap this up fairly swiftly. But it isn't ... at best it's a good characterization of particular aspects of the web's _technical_ architecture: there are other technical aspects (eg. the use of http URIs in namespace processing) and there are non-technical aspects (eg. the use of http URIs in informal or layered contexts). I don't believe it's possible to restrict the scope of Web Architecture to something for which the REST/HTTP GET/resource trio would be adequate. The gradual incorporation of URI-speak into natural language and the consequent reverse incorporation of natural language semantics into the web is unstoppable. By contrast, any issues that RDF and the Semantic Web might raise are verging on the trivial. Cheers, Miles
Received on Thursday, 1 August 2002 06:10:28 UTC