Multiple direct containment

It seems to me that a requirement allowing or disallowing multiple direct 
containment of Web resources in collections is somewhat moot.  Since we're 
mandating that web resources in a collection must have names which are 
appended to the URL path of the collection, if the repository for a web 
server decides to allow the same underlying resource to be visible through 
two (or more) different URLs, and ensures that accesses via these URLs are 
all consistent with the semantics specified in the HTTP and WebDAV specs., 
then I see no problem with it.  However, if the same server state/resource 
is accessible via multiple URLs, with each URL providing semantics which 
are consistent with the HTTP and WebDAV specifications, then each of these 
URLs is behaving exactly like a separate resource as far as the HTTP and 
WebDAV protocols are concerned.

For example,

If a repository R has a resource with ID: 454 (an unique identifier 
generated by the repository), and this repository is integrated with a 
WebDAV server such that resource #454 is exported via URLs 
"http://dav.com/A/name1.html" and "http://dav.com/B/name2.html", and both 
name1.html and name2.html behave according to the interface specifications 
of the HTTP and WebDAV specifications, then there is no conflict here, even 
though resource R, ID: 454, is directly contained in both collections.  In 
order to behave intelligently, the repository and WebDAV integration will 
have to ensure that a LOCK of either will be visible at both name1.html and 
name2.html, etc.

What I think is more problematic is when functionality is provided to 
create such a dual resource, or to add a resource directly into more than 
one collection.  This is essentially a "COPY by reference" method.  Given 
our difficulties specifying COPY by value, and the difficulties which arise 
when we try to specify behavior concerning the state of the resource (since 
it is a secret of the abstractions we are allowed to manipulate), I imagine 
the wording of "COPY by reference" might be tricky...

I don't think we can stop someone from implementing a server which has 
multiple direct containment.  But, I do think we need to be very cautious 
about functions which create new multiple direct containment relationships.

- Jim

Received on Monday, 2 March 1998 22:37:35 UTC