RE: Docushare and WebDAV model

The requirement is only that if you use an HTTP URL then it MUST follow the
specified rules. This was necessary in order to provide consistent
hierarchical behavior which was one of the big missions of WebDAV. 

If you use another type of URI then you can follow any rules you please.

			Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tuesday, August 04, 1998 6:58 AM
> To: 'w3c-dist-auth@w3.org'
> Cc: Falkenhainer, Brian C; Slein, Judith A; 'jdavis@parc.xerox.com';
> Garnaat, Mitchell
> Subject: 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&nod
> eid=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 22:09:12 UTC