RE: Clarification on MKCOL needed

I agree with you that this is a problem for all document management systems.
I believe it is the most fundamental mismatch between the WebDAV operational
model and the way document management systems work.  It affects not only
MKCOL, but all methods that result in the creation of new resources (COPY,
MKREF, PUT, MKRESOURCE).

It's also wound up with the requirement that WebDAV resource names reflect
the collection hierarchy, which the server-generated names in document
management systems generally do not do.

Document Management Systems will probably be forced to do aliasing between
client names and server names, no matter how costly and annoying that turns
out to be.

--Judy

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



> -----Original Message-----
> From: Brian Stiles [mailto:bstiles@starbase.com]
> Sent: Friday, September 10, 1999 5:56 PM
> To: w3c-dist-auth@w3.org
> Subject: Clarification on MKCOL needed
> 
> 
> How can a WebDAV server support MKCOL if the repository the server is
> built upon assigns names to newly created collections (as opposed to
> allowing clients to specify the name)?  Put another way, how can a
> client create a collection on a WebDAV server using MKCOL if the
> collection that gets created must be assigned a URI by the server?
> For example, suppose that each collection is assigned an ID that is
> unique to the database that underlies the WebDAV server and this ID is
> used to identify the collection in a URI (e.g.,
> http://foo.com/121/13/4/).  If a client wants to create a new
> collection, it must issue a MKCOL request to
> http://foo.com/121/13/4/<NEW_NAME>/ but because of the fact that the
> server essentially controls the namespace, not the client, the client
> can't know what to send for NEW_NAME.
> 
> Am I missing some important piece of information here?  I assume that
> document management systems might be likely to encounter this kind of
> problem.  If so, has anyone dealt with it?
> 
> Although it doesn't seem to be explicitly forbidden, I am assuming
> that it is inappropriate for the server to ignore the name in the
> request-URI and respond with a Location header that identifies the
> name assigned by the server.  Though this seems like a possible
> solution, it seems contrary to the intent expressed in the spec.  Or
> am I wrong in this assumption?
> 
> --
> Brian Stiles
>

Received on Monday, 13 September 1999 11:57:31 UTC