RE: Clarification of URI vs. resource

Internal members are defined in the context of the request URI used to
reference the collection.

			Yaron

-----Original Message-----
From: Jim Whitehead [mailto:ejw@ics.uci.edu]
Sent: Wednesday, November 04, 1998 2:59 PM
To: Larry Masinter; WEBDAV WG
Subject: RE: Clarification of URI vs. resource


Larry Masinter writes:
> It's hard to tell if you've addressed the problem without seeing the
> whole thing.

Agreed.  I'll place a full snapshot of the spec. online soon, and make a
post to the list giving the URL.

> The main thing to watch out for, of course, are those
> places where the spec talks about "the URI of a resource", since
> you've gone down the road of "a resource can have more than one URI".
>
> For example -- just perusing quickly --
>
> > Collection - A resource that contains a set of URIs, termed member URIs,
> > which identify member resources and meets the requirements in
> section 5 of
> > this specification.
>
> So a 'collection' is a 'resource', not a 'uri'.

Yes.

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

Good catch.  These suggested changes didn't consider multiple URIs for
non-collection resources.

It seems to me there are two ways of handling the issue of multiple URIs for
collections:

a) disallow them
b) allow them, and detail the consequences.

Disallowing multiple URIs for collection resources would certainly be
simpler to specify, but doesn't seem to address the modeling issues of
document management systems (DMS) which would like to make a single
collection visible in multiple places in the HTTP URL namespace.  Granted,
one could require that for a DMS collection to be visible in multiple places
in the HTTP URL namespace, it has to be modeled by several resources, and
then each resource has one and only one URL.  But, this seems a little
contrived.

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.  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 (or, alternately,
dereferencing member URIs via some of a collection's URIs results in
dangling aliases).  This affects resource creation methods (PUT, COPY,
MKCOL, and possibly LOCK), since they would be required to have multiple
URIs for the created resource (or dangling aliases would occur).

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


> Note that later, you say:
>
> > An internal member URI MUST be
> > immediately relative to the base URI of the collection.  That is, the
> > internal member URI is equal to the containing collection's URI plus an
> > additional segment for non-collection resources, or additional segment
> plus
> > trailing slash "/" for collection resources, where segment is defined in
> > section 3.3 of [RFC2396].
>
> 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'?
> Since it's URI is _not_ equal to the containing collection's URI
> plus an additional segment?
>
> I don't think the problem is unsolvable, but you need some way of
> determining
> the 'canonical for the purpose of determining immediate containment' of
> a URI if you follow along this model.

Good point.

> > 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.
> > Properties defined on collections behave exactly as do properties on
> > non-collection resources.
>
> 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.

- Jim

Received on Wednesday, 4 November 1998 21:15:52 UTC