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

Re: now://example.org/car (was lack of consensus on httpRange-14)

From: Roy T. Fielding <fielding@apache.org>
Date: Tue, 8 Oct 2002 16:23:42 -0700
Cc: "'Graham Klyne'" <GK@NineByNine.org>, "'www-tag@w3.org'" <www-tag@w3.org>
To: Micah Dubinko <MDubinko@cardiff.com>
Message-Id: <FBCE5819-DB14-11D6-92FF-000393753936@apache.org>

> I am asking the TAG for an opinion on the relative merits of two (not
> necessarily exclusive) worldviews:
> a) URIs in general can identify anything. http:// URI(reference)s can
> identify anything. Fragment identifiers are necessary (at least in RDF) to
> broaden the scope of http:// URIs.

How could fragment identifiers be necessary to "broaden the scope" of
http URI when the http scheme can already identify anything?

> vs.
> b) URIs in general can identify anything. http:// URIs can identify 
> anything
> that's network-accessible. thingy:// URIs (meaning something like ChrisL'
> s
> now:// or LarryM's tbd:// without getting hung up on the name) can 
> identify
> anything non-network-accessible.

http URI can identify things that are not network accessible.  Identify
and access are two separate verbs.  Whether or not other schemes are
invented to identify things that cannot ever be accessed is irrelevant
to the scope of http identifiers.  Whether or not it is "better" or
"worse" to identify those things using an http URI or some other URI
scheme is irrelevant to the Web architecture because of the principle
of orthogonal protocol specifications.

> The reason that the TAG should address b) in some manner is because
> "thousands" of developers (including four or five so far in this thread)
> have independently thunk up this technique throughout the Internet ages.

And yet none of them have been deployed, because when they actually go
to implement it they find that a new scheme is not necessary.  The only
harm in creating a new scheme is the lack of universal deployment, but
that is sufficient to require real justification and demonstrated need
in order to convince the other developers to implement.

> The question is NOT whether a) or b) can hold together consistently, 
> because
> either could, given enough force. :-) The questions are: does a
> non-dereferencable scheme model the non-networked resources better? Is it
> more understandable and less error-prone for developers? Has it already 
> been
> looked at in detail and rejected?

Non-dereferenceable schemes have been defined dozens of times -- just
look at the proposals in the old URI and URN working groups of the IETF.
Do you see much deployment of those schemes?  Does it matter whether or
not they are deployed?

If you want to use some special scheme to mean some special category of
resources, then feel free to do so.  What I adamantly oppose is the
invention of new constraints on the http scheme that are obviously false,
as demonstrated by the presence of desired current practice, for the
sake of justifying a new scheme or some hack like changing the expected
meaning of a fragment within RDF.  Neither the Web nor RDF need such a
distinction to be made.

"http" does not imply that HTTP is going to be used -- it only defines
the naming syntax: a method of defining the naming authority and name
within that authority.  The fact that it also describes an access
mechanism for attempting to manipulate the resource through the
exchange of representations via HTTP does not imply that such mechanism
is operable, accessible, or authorable by anyone, let alone some random
person using the identifier solely for the purpose of identification.


Roy T. Fielding, Chief Scientist, Day Software
                  (roy.fielding@day.com) <http://www.day.com/>

                  Co-founder, The Apache Software Foundation
                  (fielding@apache.org)  <http://www.apache.org/>

Meet me at ApacheCon 2002, Nov. 18-21, Las Vegas <http://www.apachecon.com/
Received on Tuesday, 8 October 2002 19:25:26 UTC

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