- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Tue, 18 Aug 1998 23:05:13 PDT
- To: "Yaron Goland" <yarong@microsoft.com>, "'Slein, Judith A'" <JSlein@crt.xerox.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
- Cc: "Falkenhainer, Brian" <Brian_Falkenhainer@mc.xerox.com>, "Garnaat, Mitchell" <MGarnaat@crt.xerox.com>, "'Jim Davis'" <jdavis@parc.xerox.com>, "Jim Whitehead (E-mail)" <ejw@ics.uci.edu>
Yaron, I agree that it seems to be bad form to try to use the parent property as a way of _manipulating_ parentage, but calling it a 'hack' (while, presumably, implying that relying on client-parsing and manipulation of the URL structure isn't a hack) is going too far. Certainly restricting the DAV:parents property to be read-only (or at least not requiring that it be writable) makes a lot of sense. Larry -- http://www.parc.xerox.com/masinter > Summary: A parent property is a fine hack for read-only access to flat > namespace stores but is inappropriate for providing clients with the ability > to manipulate the membership in such a namespace. > > Details: > > If someone only wishes to provide read-only access to the structure of the > tree then they can shove in a new property which clients can read in order > to determine parentage. Just write up the ID and submit for standardization. 'Submit for standardization' sounds pretty painful. Since you use the phrase 'shove a new property' instead of 'add the missing property', one _might_ infer that you _might_ not actually go along with the idea, but it's not clear. > However a property is insufficient if the goal is to provide the client with > the ability to alter the relationships of a resource with other resources. This isn't the goal. The property is for discovery, not for manipulation. > To whit, using a property to alter parentage violates a major rule of good > design: NEVER depend on side effects of setting properties because: Yes, very bad. Naughty. Improper. Wouldn't do that. Uh-huh. Nope, no PROPPATCH for DAV:parents, only PROPFIND. > A) Protocol Tunneling Is Bad Yes. Bad. Especially since there is a more direct way of manipulating containment. .... > > B) Extensibility is Good Yes. Good. The current WebDAV design lacks extensibility in an important aspect: it locks servers into the perpetual night of URL slashdom, because deployed clients NOW lack of a common and extensible way of dealing with other kinds of container/contained naming relationships. It's important to fix this NOW, before so many WebDAV clients get deployed that upgrades will be impossible. > Separation of Functionality - ... the rest of this seemed like an argument against using PROPPATCH for modifying parent/child relationships, which I agree seems like a bad idea. There are already ways of interoperable ways of modifying the hierarchy for other naming relationships, there's just no interoperable way of _discovering_ the hierarchy, which is what we're arguing should be fixed. > > I don't understand what's 'quite complex' about suggesting that there > > be a DAV:parents property and that interoperable clients that want to > > work with the typical document management based systems as well as > > file-server based systems should use PROPFIND of DAV:parents in order > > to walk up the hierarchy, rather than just trying to parse the URL > > tree. It's simple, backward compatible, doesn't cost much in terms of > > server implementation, and much more resiliant. > > > > Yes, there's a hierarchy, and yes, if you use it, there's a clear > > way to use it, but that's very different from _requiring_ that the > > hierarchy be used. > > > > Put the burden of understanding the hierarchical forms on the servers, > > not on the clients.
Received on Wednesday, 19 August 1998 02:06:48 UTC