- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Tue, 4 Aug 1998 09:57:35 -0400
- To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
- Cc: "Falkenhainer, Brian C" <BFalkenhainer@crt.xerox.com>, "Slein, Judith A" <JSlein@crt.xerox.com>, "'jdavis@parc.xerox.com'" <jdavis@parc.xerox.com>, "Garnaat, Mitchell" <MGarnaat@crt.xerox.com>
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