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

In the context of DAV, I can see things both ways, and that it would
be possible to interpret the DAV spec so that 'a resource' had
a 1-1 mapping to 'a URI', and that different URIs would be considered
different resources. However, I don't think that's consistent with
the language of the URI document, the architecture of URN resolution,
etc. I can't quite imagine how we might write a document that described
URN resolution as mapping the URN (a URI for a resource) to a URL
(a URI for a resource) without describing the relationship of the
resources represented by the two URIs as 'the same resource'.

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

In any case, I don't think it is good to leave it ambiguous for
WebDAV, since the document actually winds up making different
requirements depending on which reading is taken.

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.

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?

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.

(Should it be 'a server may accept a URI' rather than 'a resource
may accept...'?)

Is http://server/a/b a different resource than http://server/a/b/?
That is, they're two (different) collection resources? This would
seem to be the model you're advocating. unless there's a special case
that URI:resource is 1-1 except when the URI is a collection, in which
case there (may) be a 2-1 relationship, where both http://server/a/b and
http://server/a/b/ are actually considered the same resource.


Section 4.4:

#   For this simple case, the URL at which a
#   resource is accessed is identical to the URL at which the source
#   (the persistent state) of the resource is accessed.

This would be more simply said (if URLs = resources) that 
"the accessed resource is identical to the source resource",
wouldn't it?

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

-------------------
More editorial issues:

# DAV compliant
#   resources MUST maintain the consistency of the HTTP URL namespace.

Is there a definition of what 'the consistency of the HTP URL namespace'
means? It's not defined anywhere, and this sentence only gives an example.

#   However, the server can sometimes process HTML resources before they
 #  are transmitted as a return entity body.

The ability to do server-side processing is not restricted to HTML
entities.

Received on Thursday, 10 September 1998 02:43:06 UTC