RE: Docushare and WebDAV model

Well, from the examples they provided, it looks as if they *are* using
an http URL in the sense that it starts with "http:"  But the claim is
that their namespace is significantly different from the traditional
file system directory hierarchy that we think of as being behind an HTTP
server.  So that even though they think of the objects they manage as
being hierarchically organized, it works better for them to use a flat
URL of the form "HTTP://<dms-namespace>/<object-handle>".  Are they
still compliant if they do this?

Brian and Mitch, feel free to join the conversation if I'm not making
your case clear.

--Judy



> -----Original Message-----
> From: Yaron Goland [mailto:yarong@microsoft.com]
> Sent: Tuesday, August 04, 1998 10:10 PM
> To: 'Slein, Judith A'; 'w3c-dist-auth@w3.org'
> Cc: Falkenhainer, Brian C; 'jdavis@parc.xerox.com'; Garnaat, Mitchell
> Subject: 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 Thursday, 6 August 1998 13:40:07 UTC