RE: URIs-Resource relationships

> Uniform processing for URIs would have saved a lot of us a 
> hell of a lot of trouble, and still could.
> 
> Leaving the spec as vague as possible may be exciting to some 
> folks, and may avoid some categories of political irritation, but isn't 
> useful to a large group of people faced with the task of figuring out 
> exactly how these identifiers are supposed to work.

The specification is not vague.  It specifies exactly what is intended
by resource.  URI is a syntax for a resource identifier.  The URI does
not define the resource -- some person/author/community does.  When you
GET on a URI, you retrieve a representation of that resource at the
time that the response was generated.

There are literally millions of other things that could be said about
resources and about URI, but none of them could make the definition any
less incompassing without ignoring some aspect of resource space that
someone else depends upon.  Furthermore, since HTTP depends on the
entire scope, it isn't going to be limited any further.

> A spec that says "any way you want" isn't very much of a spec, is it?
> 
> RFC 2396 isn't very far from that, I'm afraid.

RFC 2396 defines everything you need to interoperate with real URI-based
systems.  It doesn't have all the information that is in my dissertation,
but it is sufficient to develop any application I have ever seen,
including anything related to XML, RDF, and namespaces.

The answer to your question is: if the existing definition of resource
is insufficient for your application, then your application is not designed
to handle the full scope of what a resource may be.  Either live with
that limitation or fix your application.


Cheers,

Roy T. Fielding, Chief Scientist
                 eBuilt, Inc.
                 2652 McGaw Ave. 
                 Irvine, CA 92614-5840  fax:+1.949.609.0001
                 (fielding@ebuilt.com)  <http://www.eBuilt.com>

Received on Thursday, 7 September 2000 15:50:37 UTC