W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2007

Re: New draft: draft-daboo-webdav-mkcol-00.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 19 Nov 2007 14:13:47 +0100
Message-ID: <47418C0B.8020700@gmx.de>
To: Werner Baumann <werner.baumann@onlinehome.de>
CC: w3c-dist-auth@w3.org

Werner Baumann wrote:
> MKCOL for non-collections?
> MKCOL should not create anything but collections. These may be special 
> kinds of collections, and there may be a body included (as proposed). 
> But never use it to create non-collections. This kind of misnomer will 
> strike back some day.


> If there are special kinds of non-collection resources, that can not be 
> created using PUT (eventually with additional XML-body), they probably 
> need a new method. Maybe this could be some kind of generic method for 
> different kinds of non-collection resources. It might be better to have 
> one method to create collections and non-collections. But this must not 
> be called MKCOL, maybe MKRES.

This was once proposed as MKRESOURCE (early drafts of the redirect 
spec), but later rejected.

> Setting properties:
> As long as the XML-body is only needed to set properties (including a 
> special resource-type), I cannot see the need for additional 
> XML-elements (mkcol and mkcol-response). Everything needed to set 
> properties is already in RFC 4918.

I would argue in favor of keeping the top level argument, because it's 
consistent with all the later WebDAV specs.

> As the extended MKCOL-method is defined to be "all or nothing", there is 
> usually no need for a response-body, the status-line will suffice. It is 
> useless to list all properties, that are set. If the request succeeds, 
> they are all set. If there is a need for some response-body in special 
> cases, multistatus and response should do the job.

Again, I would propose to leave things as defined for consistency with 
other methods.

> Special collections:
> Special collections will be defined by an additional resourcetype 
> property. As this collection may be expected to behave different from 
> standard collections, it is essential that the server knows about this 
> special kind and supports it. It must be stated clearly, that the 
> request must fail, if the server does not know this resourcetype or does 
> not support it. I am not clear about this, but I believe according to 
> RFC 4918, the server would be allowed to just create a dead property.

DAV:resourcetype can not be a dead property. Ever.

> As the special collection is defined by its resourcetype, I can not see 
> any need for mkworkspace, mkactivity and similar XML-elements. As far as 
> I can see, they just contain properties.

I think the examples contain more.

That being said, I'd propose to leave out everything about RFC3253.

> ...

Best regards, Julian
Received on Monday, 19 November 2007 13:14:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:42 UTC