RE: semantics of external members

The purpose of the external member mechanism is to provide a place to record
a set of URIs that are associated with a collection, that is it. Attempts
were made in the past to give them additional semantics but after months of
debate all these proposals were resoundly turned down as completely
unworkable. Please refer the copious, nearly endless, discussions on the
topic in the mailing archive for further details. You can also refer to
previous versions of the DAV spec which contained various proposals to
extend the functionality of external members beyond a simple storage
mechanism.

		Yaron

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	Friday, January 16, 1998 9:31 PM
> To:	w3c-dist-auth@w3.org
> Subject:	semantics of external members
> 
> I have a few questions about the intended semantics of URIs that are
> external members of collections.  In particular, I am curious about those
> URIs for which the server named in the URI is not the same as the server
> that stores the collection.
> 
> If server S has a collection C that contains an internal member P and an
> external member Q, when I do a PROPFIND on C I should expect to get back a
> multistatus that contains a results for both P and Q, right?  And this is
> independent of the identity of the server in the URI for Q.
> 
> Does this mean I can also do a PROPFIND on server S for the URI Q?  and
> likewise a PROPPATCH?
> 
> Surely this must be so, since it would be weird to be able to retrieve the
> property by asking the collection (with Depth non-zero), but not directly.
> And if I can do a PROPFIND (of a non-live property) I ought to be able to
> do a PROPPATCH.
> 
> And if I can do a PROPPATCH, I should be able to do a LOCK and UNLOCK, too
> 
> Now in that case, does WebDAV say anything about the semantics of a GET on
> Q?  Is it silent?  May a server return 404? (not found)?  May it return
> 302
> (Moved Temporarily)?
> 
> Near as I can tell the spec is silent on these matters, and I wish it said
> something explicitly.
> 
> Likewise, if URI Q is a member of two collections on S, it must be
> external
> to at least one of them.  Does the spec say anything about whether the set
> of properties visible on Q MAY or MUST NOT in any way on which collection
> it is part of?  Imagine, for example that two different users, A and B,
> each have a collection (Ca and Cb) stored on S, and they each add Q as an
> external member to their collections.  If A sets a property on Q, will B
> see it, too?  This might surprise B.  
> 
> I hope there are well defined obvious answers to these questions, that
> someone will tell me what they are, and that the next version of the
> documentation will include them.
> 
> best wishes
> 
> Jim

Received on Saturday, 17 January 1998 18:26:11 UTC