FW: Docushare and WebDAV model

I want to forward to the group this note from some repository developers
at Xerox.  It is their view that most, if not all, document
repositories, would prefer to use handles to identify the objects they
control, and not paths in a URL hierarchy.  They would like to see the
requirement that the URLs of DAV resources reflect the URL hierarchy
(see section 4 of the spec) be removed, or at least weakened to
"SHOULD".

Can anyone reconstruct the original rationale for this requirement?

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


-----Original Message-----
From: Falkenhainer, Brian C 
Sent: Monday, August 03, 1998 4:18 PM
To: Slein, Judith A
Cc: Garnaat, Mitchell; 'Jim Davis'; Falkenhainer, Brian C
Subject: RE: Docushare and WebDAV model


I'm not sure. Some of the problem may be that we're using different
terminology, etc. On the one hand, we think or our "Collections" as true
collections in the DAV sense. They have member objects, if you delete a
collection all of its members get deleted, if you update a collection's
permission (ACL) structure its members get affected (if you do 'unify'),
all "add" operations (e.g., MKCOL) are with respect to adding something
to a specific collection, etc. When you do a PROPFIND with Depth=1
against a DocuShare 2.0 server, you get the targeted collection and all
of its immediate members, just like in the WebDAV examples.

Other the other hand, we make a fairly big deal out of the fact that
location is just another property and any object can have more than one
location. All object references are based on the object itself (its
URI), not its location in the hierarchy. I've never found these two
views to be in conflict. You ask below about DMSs that work this way. I
think most of them do. They manage objects, not locations in a file
system. For example, here is an OpenText URL:
http://demo.opentext.com/livelink/livelink?func=doc.browse&nodeid=22278
This opens their demo collection called "Gizmo". It resides inside the
collection called "Library". Inside Gizmo are other collections and
documents, each having a URL of the same form but with a different
nodeid. Their file URLs have a different form:
http://demo.opentext.com/livelink/livelink/22677/Bus_Schedule.doc?Func=d
oc.copyto&nodeid=22677
but same issue (my guess is that this URL form lends support for
renditions and/or versions, but I'm just guessing). DocuShare works in
much the same way and back when we spent a lot of time with AltaVista
Forum it did the same thing too. I'm sure Documentum (with RightSite)
must certainly do it this way as well. All of these products treat
collections as real collections, with all the behaviors that implies.
They just don't use a path-driven referencing model.

My preference is that WebDAV simply insist on a valid URI for each
resource and remove the two sentences placing syntactic requirements on
URLs to denote containment relationships. Containment should be
determined semantically through GET and PROPFIND, not through URL
syntax. That's how our client does it. Even if WebDAV simply said
"SHOULD follow a path-driven namespace" instead of "MUST follow a
path-driven namespace" we'd be fine.

More fundamentally, I'd like to know what the motivation was for those
couple sentences. We've been discussing proposals for how to co-exist
with the requirement, but I haven't heard an explanation for why it's in
there in the first place. I'm missing the rationale.

-Brian

-----Original Message-----
From: Slein, Judith A 
Sent: Monday, August 03, 1998 2:51 PM
To: Falkenhainer, Brian C
Cc: Garnaat, Mitchell; 'jselin@crt.xerox.com'; 'Jim Davis'
Subject: RE: Docushare and WebDAV model


I've been trying to express something concise that expresses your
problem, to send to the WebDAV working group.  But so far I'm failing.
At this point I can't see that there is a problem.

The fact is that you have a flat namespace.  Everything is an internal
member of one root directory.  The things that belong to that directory
include collections.  But membership in those collections is only by
reference.  So the base WebDAV spec doesn't have anything to say about
that.  The URLs it would expect to see from you would be of the form
http://<identifier-for-your-space>/<object-identifier>, which is exactly
what you wanted, I thought.

Maybe there's still a suggestion you'd like to make to WebDAV.  You can
imagine a DMS that requires every object to be an internal member of
some collection. (So that if the collection is deleted, so will its
internal members be deleted.)  But the DMS still assigns a unique
identifier to each object it manages, an identifier that is independent
of which collection it belongs to.  And it is this identifier, not any
hierarchical information, that it really wants to see in requests.  The
identifier will always be good, no matter where the object moves over
its lifetime; but hierarchical information might be out of date.  Is
this what you want to say?  Do we know of DMSs that work like this?

Judith A. Slein
CR&T/ADSTC
jslein@crt.xerox.com
8*222-5169

Received on Tuesday, 4 August 1998 09:58:46 UTC