Re: httpRange-14 , what's the problem

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