Re: ISSUE-81 (resource vs representation)

On Sep 28, 2009, at 1:27 AM, Ian Hickson wrote:

> On Sun, 27 Sep 2009, Roy T. Fielding wrote:
>>
>> Stop the bullshit, Ian.  The terminology used by the majority of Web
>> developers is that a URI is used to identify a resource for the  
>> sake of
>> manipulating its current state.  Maybe if you spent a little more  
>> time
>> talking to Web developers instead of just browser developers, you  
>> might
>> understand why the architecture is specified the way it is currently.
>
> With all due respect, my experience disagrees with yours. I don't have
> data to back this up; maybe we could collect some?
>
>
>> I've had the same argument a thousand times over the past fifteen
>> years and the Web resource still means the same thing today.
>
> It seems to me that if you've had the same argument every two  
> months for
> fifteen years that maybe you're wrong.

No, there is just a very large number of people with preconceptions
about the Web based on ignorant documentation.  Once I explain to them
the reason for the definitions, they all use the terminology in the
way I suggested.  It takes a ridiculous amount of my time to do so,
but it has nothing to do with being "theoretical" or "abstract".
It is about knowing the subject area and the scope of implementations.

>> The same term is used for a lot of things that are general computing
>> resources, but no spec considers the thing identified by a resource
>> identifier to be a bag of bits.
>
> CSS2:
> #   <uri>
> #          The value is a URI that designates an external resource  
> (such
> #          as an image).

It is standard practice to use simple-to-understand examples to  
illustrate
the more normative prose.  Some specs do it better than others.

> HTML4:
> #  2.1.1 Introduction to URIs
> #
> #   Every resource available on the Web -- HTML document, image, video
> #   clip, program, etc. -- has an address that may be encoded by a
> #   Universal Resource Identifier, or "URI".

examples.

> ECMAScript 3.1:
> #  15.1.3 URI Handling Function Properties
> #
> #   Uniform Resource Identifiers, or URIs, are strings that identify
> #   resources (e.g. web pages or files)

examples.  Though I recommend not getting into a debate over what
"web page" means.

> SVG 1.1:
> # A URI reference is specified within an href attribute in the XLink
> # [XLINK] namespace. If the default prefix of 'xlink:' is used for
> # attributes in the XLink namespace, then the attribute will be
> # specified as xlink:href. [...]
> # If the xlink:href references a stand-alone image resource such as a
> # JPEG, PNG or SVG file [...]

examples, though the reference to "file" is an obvious bug.

> XMLSchema (Part 1: Structures; Second Edition):
> # Their schemaLocation attributes, consisting of a URI reference [...]
> #
> # 1. If the actual value of the schemaLocation [attribute]
> #    successfully resolves one of the following must be true:
> #    1.1 It resolves to (a fragment of) a resource which is an XML
> #        document (of type application/xml or text/xml with an XML
> #        declaration for preference, but this is not required)

Maybe Paul can explain why they got that one wrong.

> PICS services 1.1:
> # A URL describes the location and means of retrieval for a single
> # document.

Obviously wrong on several counts.  This is why SDOs should never be
allowed to develop open standards on closed lists.

> PICS labels 1.1:
> # document
> #    Any item that can be referred to by a URL. Also known, in other
> #    contexts, as a "hypertext page" or a "resource."

You will have to ask TimBL about his definition of "document".
It is not a bag of bits.

> So again, with all due respect, I disagree.

I know you disagree.  I also don't care whether you agree or disagree.
The distinction is important whether you believe it to be so or not.

>> A resource is not a bag of bits.  A bag of bits can't act as a  
>> gateway
>> for sending SMS messages to cellphones.
>
> Indeed, that would be an HTTP server.

No, an HTTP server does many things for many resources.  A resource
identifier is used to tell the server which of those many things is
being requested by the client.  Therefore, the resource identified
is the continuation of things over time that the HTTP server
associates with the requests for that URI.  In many cases, but not all,
that sameness over time is going to look like a bag of bits.

>> A bag of bits can't maintain a constant sense of identity when the  
>> bits
>> change upon every observation.
>
> Indeed, resources don't have senses of identity.

People do.  When people insert a reference into a hyperlink,
they are identifying what they think future hypertext readers
will want to traverse to (or embed, run, etc.) at the time
that those people activate the link.  When I point to a twitter
feed using a hypertext link, I do not want people to see the
same bag of bits that I did when I viewed the page on the day
I made that link.  I want them to see the current state of the
resource that is being identified, particularly when it has a
time-varying nature that is significant to its value as a
resource, such as the example of a twitter feed.

>> A bag of bits can't respond to a POST with a 204.
>
> Indeed, only HTTP servers do that.

HTTP servers do that in response to a PUT or a POST on a specific
URI that identifies a resource which, for any number of possible
reasons, acts as a representation sink.  The URI identifies a
resource and that resource is not a bag of bits, nor is a bag of
bits returned in a response to that request.  Your definition is
therefore wrong.

>> A bag of bits does not remotely control a robot arm on the other  
>> side of
>> the world.
>
> Indeed, HTTP servers do that.

Because of a request on a URI that identifies a resource that is
not a bag of bits.

>> A bag of bits does not in any way appreciably reflect the  
>> significance
>> of "http://twitter.com/hixie": not today, not last week, and  
>> certainly
>> not as a continuation over time.
>
> Indeed. Nor do resources. The URL "http://twitter.com/hixie" has as  
> its
> significance "use the HTTP protocol on the server with host name
> 'twitter.com' on port 80 with path '/hixie'"; it doesn't have any more
> actual significance than that.

It is a resource for the person traversing the link.  The protocol
associated with resolving the identifier for retrieval of the current
resource state is the mechanical process you describe (if we ignore
the presence of caches).  People don't add links for the purpose
of identifying insignificant protocol actions -- they add them to
point to a resource (an available source of wealth; a new or reserve
supply that can be drawn upon when needed; a source of aid or support
that may be drawn upon when needed).  It is not a bag of bits.

....Roy

Received on Monday, 28 September 2009 18:19:01 UTC