RE: Hierarchical URLs and Collections

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 UTC