RE: Clarification of URI vs. resource

I've followed this discussion and at this point I don't see a problem.
That is, none of the examples presented seem to have paradoxical or
non-sensical consequences.  I speak as one who has implemented WebDAV.

I will say that in such implementations, allowing multiple URIs to refer to
the same resource requires some care in how one stores properties.  But
this has to do with difficulties in programming, not in understanding the
intentions of the spec, which seem to me to be clear.

In sum, anyone who thinks there is a problem should present an actual
example of inconsistency or paradox that could arise.

The remainder of this message comments specifically on the interchange
between Larry and Jim Whitehead.

At 02:58 PM 11/4/98 PST, Jim Whitehead wrote:
>Larry Masinter writes:
>> > Internal Member URI - A Member URI that is immediately relative
>> to the URI
>> > of the collection (the definition of immediately relative is given in
>> > section 5.2).
>>
>> But you say _the_ URI of the collection.

I don't think this is a problem.  In context, this is talking about the URI
of a member of a collection.  The collection resource itself may have many
URIs, but for the purposes of any single WebDAV request, the other URIs
don't matter.
Likewise, the URIs of the internal members are specified relative to the
URI of the container.

>It seems to me there are two ways of handling the issue of multiple URIs for
>collections:
>
>a) disallow them

No need for that.

>b) allow them, and detail the consequences.

>The current definition of a collection is pretty usable even if there are
>multiple URIs for the collection, since member URIs are currently defined as
>being immediately relative to the base URI of the collection.  But, if the
>member URIs are immediately relative to *a* base URI of the collection, then
>the definition still works.  

There's no need for that.  The only way a client can discover the URIs of
the members of a collection is by doing PROPFIND, traversing down the tree.
The client provides the URI of the collection, and the URIs in the PROPFIND
response are relative to that.

>It has one repercussion: if a collection has
>more than one URI, then every resource referenced by the member URIs of the
>collection also needs to have more than one URI 

if a collection has more than one URI, then a client will reach it by two
paths.

>For example:
>
>A collection resource, R, has the following member URIs:
>
>mem1.html
>mem2.html
>mem3.gif
>
>The collection resource itself has the following URIs:
>
>http://example.com/collect1/
>http://example.com/collect2/
>
>This implies that the resources available via URIs:
>
>http://example.com/collect1/mem1.html
>http://example.com/collect1/mem2.html
>http://example.com/collect1/mem3.gif
>
>Would also have to be available via URIs:
>
>http://example.com/collect2/mem1.html
>http://example.com/collect2/mem2.html
>http://example.com/collect2/mem3.gif

And what's the problem with that?  Isn't this exactly the semantics you
want by having two names for the collection?

>> If I have a collection with
>> URIs  
>> http://server1.company.com/collection and also
>> http://server1.company.com/COLLECTION, then is
>> http://server1.company.com:80/Collection/frob an 'internal member'?

of "collection"?  No.

http://server1.company.com/collection/frob is an internal member of
 http://server1.company.com/collection

http://server1.company.com/COLLECTION/frob is an internal member of
 http://server1.company.com/COLLECTION

but nothing is known or knowable about the relation between collection/frob
and  COLLECTION/frob.  You didn't say anything about "Collection" (is this
a third name for that collection?) so I don't know about that one.

What's the problem?  It's not as if the client is getting (from random
sources)  sets of URLs with randomly permuted upper and lower cases.  It's
presumably exploring a WebDAV space in an orderly way.  We expect the
server to be orderly too.  It may well be that some WebDAV server would be
case insensitive.  In this case, for a URL of length n, there are 2^n
variations on the name, all of which lead to the same resource.  You don't
expect the  server to list them ALL when enumerating a collection?  No, it
will list just one of them, unless they are truly being used as synonyms
(as for example when one has a set of collections named according to
release version and a synonym collection that points to the most recent one.)

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

Yes.  This is the only sensible thing to say.  The spec 11.9.1 says
something close to this, and I think was even intended to say exactly this,
but does not quite say it right.

>> Do you really mean 'the same URI' or do you mean URIs for the
>> same resource?
>> If http://foo.com/bar/blah and http://foo.com/bar/BLAH are two URIs for
>> the same resource, can both of them belong separately to the
>> http://foo.com/bar/ collection?
>
>The same URI.  For example, since every part of a URI which isn't a domain
>name is case sensitive, /blah and /BLAH are two different URIs, and hence
>could both be part of the same collection.

yes.  

I would say, from the standpoint of a server implementor, that in
discussing this example, I would distinguish between 
  1) The server is doing case folding.  URLs are being canonicalized.
  2) The server respects case, and these are genuinely two different URLs
that happen to resolve to the same resource, because of the way the links
happen to be set up. 

I would say to a server implementor that in case 1 (is it even allowed, by
the way?  that is, does RFC 2068 *allow* case folding?) you should pick one
case and use it consistently in PROPFIND responses.  either:
  a) use the case in the PROPFIND request
  b) use some canonical case.

Case 2 is no difference in principle from
 http://foo.com/bar/blah 
and
 http://foo.com/bar/nusrat
or for that matter
 or http://foo.com/bar/zorba/noise/nusrat

Received on Monday, 9 November 1998 21:10:19 UTC