Re: aliasing and other (primarily) editorial issues with -protocol-08

>I suppose I'm surprised that the URI document isn't clearer on this
>point.

It is about as clear as it can get without belaboring the point
or specifying something that isn't the case for all resources.
I've been busy writing a paper about the Web's architectural
style this past month and a good part of it tries to explain the
relationship between URI and resources.  Most of it is just a rehash
of what I already wrote for the URI spec's introduction, but I include
more rationale as to why resources are defined the way they are.

A brief summary is that a resource is a conceptual mapping, not a
chunk of state.  It is possible to have both many names for the
same resource (many URI that represent the same conceptual mapping)
and many resources that point to the same chunk of state (URI with
different conceptual mappings that just happen to point to the same
representation at a certain point in time).  Thus, the 1:1 model
does not adequately describe resources even though it is sufficient
to define the namespace requirements.  Likewise, the allocation of
the 'chunk of state' within a server has no relation to a resource
other than as the endpoint of a mapping, and thus it doesn't make
sense for WebDAV to require anything along those lines (and, as far
as I know, it doesn't).

I hate to sound like a broken record, but the problem with the WebDAV
specification is not on the requirements it makes, but rather on using
terminology that makes the requirements seem like they apply to more
than what is actually being specified.

>For example, when the spec says:
>
>>    Any given internal member MUST only belong to the collection once,
>>    i.e., it is illegal to have multiple instances of the same URI in a
>>    collection.

It is in fact making a very simple requirement in a very complicated
way by using the wrong terminology.  What it should say is

   Each name must be unique within a given namespace.

Because the whole issue of multiple "entries" appearing within a
single "collection" is totally irrelevant when you aren't defining
what we would normally refer to as a collection.

>If you take the 1-1 model, this basically says that it is OK to have
>the same 'chunk of state' as an internal member of a collection more
>than once, as long as it is reached using a different URI, e.g.,
>you could have a "http://server/cars" resource with internal members
>"http://server/cars/Ford" and  also "http://server/cars/FORD".
>In this situation, the restriction makes no sense -- what purpose
>does it serve?

No purpose other than to answer a question leftover from when a
collection was equivalent to a directed graph.

>There are other places where the spec seems to read awkwardly if
>URI:resource were 1:1. For example, the wording in section 4.1 on
>"Collection Resources":
>
>#   There is a standing convention that when a collection is referred to
>#   by its name without a trailing slash, the trailing slash is
>#   automatically appended.  Due to this, a resource may accept a URI
>#   without a trailing "/" to point to a collection.

Ummm, this is bogus.  If there is no resource without the trailing slash,
and the server feels like helping the user, it might REDIRECT the request
to a DIFFERENT RESOURCE that is, in fact, the collection.  At no time
is the URI without a trailing "/" the same resource as the URI with a
trailing "/" within a good server implementation of HTTP.

>#   Sometimes the entity returned by GET is the output of a data-
>#   producing process that is described by one or more source resources
>#   (that may not even have a location in the URL namespace). 
>
>In this paragraph, it seems that URI:resource might be 0:1, i.e.,
>if there are resources that don't have URLs.

Everything and anything that can be identified can have a URI, and
certainly anything within a server already does have a URI (the file
scheme gets around).  What it should say is that they might not be
accessible independently, since the ability to access is separate from
the fact that they are resources.  While it is certainly possible for
a resource not to have a URI, there is no need for WebDAV to even
think about them because if it can't be identified, it can't be used.

I should also mention, since it has come up here and on the URI list
a few times, that a good HTTP server administrator does not allow
multiple URI to the same resource to be accessible unless there
is a good reason (such as differentiated access control).  The common
case is for the case-insensitive or misspelled URI to be externally
redirected to the true URI, thus helping a clueless user while at the
same time preventing an exponential explosion of resource references
when spiders come to index your site.  Like the case with the trailing "/"
redirect, these other resources do not exist at the time of the redirect.
The server is simply making a temporary (and very unstable) mapping
based on an implementation decision that is limited to the GET method.

....Roy

Received on Thursday, 10 September 1998 05:30:36 UTC