W3C home > Mailing lists > Public > www-tag@w3.org > August 2007

Re: New Editors Draft of the httpRange-14 Finding

From: Roy T.Fielding <fielding@gbiv.com>
Date: Tue, 21 Aug 2007 13:49:22 -0700
Message-Id: <39B6523C-8FEA-4065-9542-015C28257500@gbiv.com>
Cc: "'www-tag'" <www-tag@w3.org>
To: Rhys Lewis <rhys@volantis.com>

On Aug 21, 2007, at 4:53 AM, Rhys Lewis wrote:
> There is a new version of the editor's draft of the httpRange-14  
> finding at [1]. This has been prepared for discussion at the next  
> TAG F2F in September.
>
> ...
> [1] http://www.w3.org/2001/tag/doc/httpRange-14/2007-08-31/ 
> HttpRange-14.html

I am not pleased with this.  HTTP is fundamentally about defining a
pure interface protocol in which clients cannot make assumptions
about how resources are implemented and servers cannot know what
clients are intending to do with the representations.  That's how we
get the complete lack of coupling between systems.

Yet this draft is almost entirely about a rather speculative (and
mostly inaccurate) model of typical Web resources and a bunch of
incorrect theories about what a client can guess about the resource
implementation on the basis of singular interactions with that
resource.  This is exactly why I opposed the httpRange-14 issue as
being such a poorly thought-out view of how HTTP works, and why our
agreed resolution contained none of this incorrect speculation.

The following sentences from the draft are all incorrect:

    Dereferencing HTTP URIs
       --dereferencing the "http" scheme is defined in RFC 2616

    The World Wide Web (Web) is an information space in which the  
items of
    interest are known as resources.
       --the Web is a dynamic graph of relationships among resources
         that can be traversed as hypertext, manipulated as a graph,
         or entered by reference.  These relationships are
         expressed by each resource in the form of zero or more
         representations that may contain links to resources.

    The URIs used in the Web are based on the HTTP [HTTP] scheme.
       -- No, all schemes are used in the Web, and that one is called
          the "http" and "https" schemes.

    A URI uniquely identifies a resource. However, on its own, a URI  
is not
    enough to provide a resource with a presence on the Web. For a  
resouce to
    have a Web presence, there must be a means by which it can be  
accessed.
    HTTP specifies the way in which such access can occur and defines  
the
    various participants in the process. Until the appropriate steps  
have been
    taken to create a Web presence for a resource, attempts to access  
it will
    fail.
       -- There is an N:1 relation of URIs to resources.  Resources may
          be identified by many different URIs, and perhaps many  
schemes.

    Once a resource has a Web presence, its URI provides the information
    necessary to allow it to be accessed.

       -- No.  For each URI, there exists a defined dereferencing
          algorithm (if any dereference is desired) that describes
          the basis for requesting authoritative access to that  
resource.
          Whether or not it is accessible is not known by the URI.

    A Web presence allows additional information to be associated  
with a URI.
       -- So does a lot of things, on and off the Web.  In this case,
          you mean representations of the resource's current value, so
          just say so -- all this walking around the bush is not going
          to help the reader.

    In some cases the association will be direct and
    the additional information will be available directly by  
accessing the Web
    presence associated with the URI itself.
       -- Huh?  "accessing the Web presence" sounds like one of those  
bad
          TV series where actors pretend to communicate with the  
departed.

    The relationship between a resource and the Web presence that  
supports
    access to it is important. If an author makes an assertion about a
    resource, its Web presence should behave in a manner that  
supports that
    assertion. To do otherwise would be misleading.
       -- No, the Web presence, when there is one, defines the nature of
          a resource in the form of maintaining a consistent mapping of
          requests to values in accordance with the owner's intended
          semantics.  If the owner makes consistent mistakes, then the
          resource is defined by those mistakes.

    Including a link in a Web page is one mechanism that authors have  
for
    making assertions about resources. The text associated with a  
link is an
    assertion about the resource that the link identifies. Of course,  
in Web
    pages, such assertions are meant only for human users.
       -- Text association is meant for everything.  Google works.

    Authorities MAY create a Web presence for any resource whose URI  
they own.
       -- that conflicts with webarch.  They SHOULD.

    Many resources that have a Web presence are actually documents.
       -- no, some resources always have a value that corresponds to the
          generalized idea of a "document" in virtual form.

    Documents provide physical representations of bodies of information.
       -- no, they are an abstraction that can be realized on paper or
          bits or sound or ...

    A document might, for example, provide a description of the planet
    Mars (see for example [MARS]).
       -- it might contain such a description.

    URIs allow documents to be uniquely identified as resources in  
the Web.
       -- that is ambiguous

    In addition, their Web presence allows the information they embody
    to be accessed and retrieved.
       -- resources may provide representations.  Representations must
          be consistent with the resource value at that time.  If the
          value is a document, then the representation will be in one
          of the many formats that can be used to represent a document.

    Normally, such retrieval is direct.
       -- no, it is almost never "direct".  indirection is everywhere.

    The resource itself consists of a body of information that is
    amenable to transmission across the Web within suitable messages.
       -- no, the resource is a continuum over time -- only its value
          at any given point in time can consist of a body of  
information.

    In general, we call such resources information resources (see for  
example
    [AWWW] section 2.2) because their essence is information.
       -- their essence is a function of information over time

    To allow transmission across the Web, it must be possible to  
represent the
    information associated with a resource, such as a document, in a  
suitable
    form.
       -- "across the Web" has redefined the Web

    For example, HTTP, specifies that the information must be
    represented as a stream of octets.
       -- no, it doesn't.  HTTP specifies that entities are delimited on
          octet boundaries.

    In addition, the person or system
    making the request, for the information associated with the  
resource, may
    also place constraints on the representations that are considered
    acceptable. For example, two different requesters might ask for the
    information in different languages. One might specify Italian, while
    another might specify Japanese. The mechanism, by which the Web  
presence
    of a resource can be accessed, is able to support such constraints.
       -- it might be, but that isn't relevant.

    Whether the requested representations are actually available for  
a given
    resource depends on the nature of the materials provided in  
support of its
    Web presence.
       -- whatever happened to being "on the Web"?  In any case, this
          grossly oversimplifies HTTP.

    When we use the term representation, we mean specifically a form  
of the
    information, associated with a resource, that can be transmitted  
across
    the Web.
       -- why?  I can build a Rube Goldberg book retrieval system based
          on URI dereferencing.  I could do a more global version of  
that
          using Amazon, were it not for the minor detail of payment.

    The architecture of the Web [AWWW] clearly separates the notion
    of a resource from that of the representations which may be  
provided by
    its Web presence.
       -- huh?  I think you mean that they are different, but co- 
dependent.

    Although we recognize that representations are returned in  
response to
    requests made to the Web presence of a resource, for brevity,  
it's often
    convenient to talk about the representations of a resource.
       -- representations are returned by the server responsible for
          mapping the resource identifier to representations according
          to the defined semantics of the identified resource.  Is that
          what you mean by Web presence?  It is less precise.

    Documents are not the only kind of information resource. The  
information
    associated with some resources is provided by computing systems.  
These
    perform work when the Web presence of the resource is accessed. Some
    systems might be able to retrieve data from sources that do not  
themselves
    have a Web presence. They may also perform computations in order to
    assimilate the information that will ultimately be returned to the
    requester in a suitable representation.
       -- What on earth does this have to do with anything?  The
          implementation is irrelevant.  The entire section is wrong.

    Systems, like the one provided by Joan's bank, which process  
requests and
    dyamically create representations are clearly not themselves  
documents.
       -- Apparently, the notion of "document" has redefined itself.

    Probably the most widely recognized type of information resource  
on the
    Web currently is the Web page.
       -- I feel like Mr. Bill.  NOOOoooooooooooooooo....

I have no time to continue with this.  I suggest that the TAG drop
this action item and move on.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>
Received on Tuesday, 21 August 2007 20:49:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:47 GMT