Re: semantics of external members

Inadvertently caught by the spam filter.

- Jim

-----Original Message-----
From:	Mary Holstege [SMTP:holstege@firstfloor.com]
Sent:	Friday, January 16, 1998 10:35 PM
To:	Jim Davis
Cc:	w3c-dist-auth@w3.org
Subject:	[Spam?] Re: semantics of external members


Jim Davis writes:
> 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?

I would say so. 

> 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

We have found it useful in our product thinking to see there as being a
distinction between intrinsic document properties (last modified, content
length, content type, etc.) and what we call "item properties" which it has by
virtue of its relationship to a collection (a name, a position in the ordering,
a bunch of other product-specific things).  When you set a document property,
then surely it doesn't matter which collection it is 'in' -- and for an
external URI, surely it can exist 'in' no collection at all -- and therefore,
yes, one rational position to take is that it changes everywhere.  On the other
hand, clearly item properties are collection-specific.  However, we have also
found that indeed it is disquieting to people to have someone changing a
document property in their collection also changing it someone else's
collection.  

In summary: I think it is possible to argue it both ways, and the spec should
allow for either.

	-- Mary
	   Holstege@firstfloor.com


| Mary Holstege, PhD                      (650) 254-5161
| FirstFloor Software, Inc.               (650) 968-1193 (Fax)
| 444 Castro Street, Suite 200            mailto:holstege@firstfloor.com
| Mountain View, CA 94041                 http://www.firstfloor.com

Received on Sunday, 18 January 1998 19:50:38 UTC