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

Roy Fielding wrote:
> 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).

This makes sense to me.

> 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.

When I read this, I first went, "broken record? What broken record?"  Then I
went "namespace -- what an overloaded term!"  However, checking through the
list archives I find:

http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0095.html

which was posted on January 26, 1998, where Roy advocates the use of the
term "namespace" instead of "collection", and discusses containment models.
Of course, not having been involved in the XML Namespace discussion,
"namespace" might seem like a less overloaded term than collection.  But,
given that the DAV spec. currently uses the term "namespace" with its XML
meaning, it behooves us not to reuse the term "namespace" when discussing
collections.

> 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.

Reading though the DAV spec., I agree that the wording of the terminology in
the collections section could be more precise.

In particular, I do like Roy's new wording for this requirement:

> Each name must be unique within a given namespace.

Except I'd change it to read:

Each collection member URI MUST be unique within a given collection.

Although, this is *exactly* equivalent to the existing language in the spec.
which reads:

"A collection is a resource whose state consists of at least a list of
internal members and a set of properties..."

"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."

Granted, this last sentence would be more clear if it read, "Any given
internal member *URI* MUST ...", but in combination with the definition of a
collection, the implication that the internal member is a URI seems fairly
clear.


> >#   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.

I'm OK with tweaking the wording here to say that this is due to a
redirection, since I agree that a client cannot know ahead of time whether
http://foo.bar.com/a and http://foo.bar.com/a/ are the same resource -- only
the server has this knowledge.

- Jim

Received on Thursday, 10 September 1998 14:19:17 UTC