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:06:48 UTC