RE: Hierarchical URLs and Collections

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.

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. 

To whit, using a property to alter parentage violates a major rule of good
design: NEVER depend on side effects of setting properties because:

		A) Protocol Tunneling Is Bad

HTTP Feature Usage - HTTP headers and other re-usable features are method
based. However commands in a PROPPATCH have an ill-defined relationship with
those headers thus, for all intents and purposes you rob yourself of access
to those headers. In other words, you have created your own protocol which
you are tunneling through HTTP.

Error Reporting - Like HTTP headers, HTTP errors are also method based. If
setting the property results in some sort of execution error, with its own
body and the like, you end up having to re-invent the HTTP response format
inside of the multi-status response. Again, you are tunneling your own
protocol through HTTP.

		B) Extensibility is Good

Separation of Functionality - One of the most powerful and compelling
features of HTTP is its easy extensibility. Need to support a new feature?
Just drop in an ISAPI (NSAPI, Module, CGI, etc.) extension. Thus a server
can build up its functionality piece by piece, adding notification support
here, PROPPATCH support there, etc. If you execute commands through side
effects of properties then you end up having to replace your property system
in order to support the new command. That is, the current extension you have
support PROPPATCH may not support your "Cook my bread when I set the value
of the "foo:bread" property to 1" feature thus requiring you to replace your
current PROPPATCH extension with a new extension that both supports
PROPPATCH and your foo:bread functionality. When you want to add your
larry:coffee functionality you are in a bind. You could wait for someone to
create the universal interface for hooking functionality into property
systems but given that there are already 4+ such interfaces just for
supporting new HTTP methods I would suggest you will be in for a long wait.

Atomicity Guarantees - PROPPATCH guarantees atomicity for its component
commands. Thus any side effects must also be made atomic. Requiring every
functional extension to support rollback is a pretty tall order and likely
to discourage extensions.

Thus you should use methods to maintain the state graph. Since the
versioning folks are doing the exact same thing it seems silly not to
leverage their work.

		Yaron

> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Tuesday, August 18, 1998 1:01 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 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.
> 
> Larry
> --
> http://www.parc.xerox.com/masinter
>

Received on Wednesday, 19 August 1998 01:40:22 UTC