W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

RE: fragment identifiers

From: Joshua Allen <joshuaa@microsoft.com>
Date: Thu, 25 Jul 2002 15:45:10 -0700
Message-ID: <4F4182C71C1FDD4BA0937A7EB7B8B4C105DCDC52@red-msg-08.redmond.corp.microsoft.com>
To: "Roy T. Fielding" <fielding@apache.org>, "Sean B. Palmer" <sean@mysterylights.com>
Cc: <www-tag@w3.org>

> That problem is simple to fix.  It is natural to want to make
> about resources and about representations of resources.  It is

Easy for you to say that it's easy to fix, at least

> of representations over time.  In other words, the reason that REST
> distinguishes the two is precisely because we wanted to solve that
> back in 1995.  It is solved for HTTP/1.1.  Now we just need to find
> corresponding syntax for it in RDF.

With all due respect, REST doesn't even deal with the problem, because
the only thing that anyone ever actually deals with is a
representations.  The actual "resource" in REST is a theoretical figment
of someone's imagination, and requires absolutely no consensus to have
HTTP work.  You can declare that your http: URL points to a beach until
you are blue in the face, and I can declare that it points to a "web
page", and none of it will matter -- the web page still works.

In other words, for HTTP this is simply sophistry.  If we ever want the
web to progress beyond the shackles of synchronous HTTP GET, we need to
deal with the problem as a practical matter.

Apparently some people think that HTTP has no limitations, has infinite
range, and solved every problem long ago.  I think HTTP/REST is fine for
what it does, but it's a bit silly to say that it's the hammer that can
pound in every screw.

> tool, and not the tool itself."  This reasoning assumes that people
> would not want to make statements about documents that describe other
> documents (not just other objects outside of Web-space), and therefore

No it doesn't.  In fact, this reasoning is the only reasoning that
*permits* that.
Received on Thursday, 25 July 2002 18:45:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:52 UTC