W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

RE: Hierarchical URLs and Collections

From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 18 Aug 1998 23:22:14 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D087923EB@RED-MSG-59>
To: "'Larry Masinter'" <masinter@parc.xerox.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>
The property solution suffers from the problems identified, thus making it
unsuitable for standardization especially in face of the more complete
solution the versioning group is tasked with providing.

> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Tuesday, August 18, 1998 11:05 PM
> To: Yaron Goland; 'Slein, Judith A'; 'WebDAV'
> Cc: Falkenhainer, Brian; Garnaat, Mitchell; 'Jim Davis'; Jim Whitehead
> (E-mail)
> Subject: RE: Hierarchical URLs and Collections
> 
> 
> 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:22:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT