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

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.

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.

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.

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.

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.

Extensions:
When considering the inclusion of an XML-body in MCOL, I also would 
prefer to make this more generic and include other methods, including 
PUT as well.
Additionally, why only set properties. It would be nice, if a 
LOCK-request could be included too. This would not only save one 
round-trip (not such important), but avoid race conditions. But allowing 
a LOCK-request in the XML-body would require a new container-element for 
the request-body. It should be something generic, like a "request"-element.

Werner

P.S: "displayname"
This example from the draft is how not to use it:
          <D:resourcetype>
            <D:collection/>
            <E:special-resource/>
          </D:resourcetype>
          <D:displayname>Special Resource</D:displayname>
Why repeat the value of another property. But displayname is useless 
anyway. Never heard of another "name", that must *not* be used for 
identifying.

Received on Sunday, 18 November 2007 16:44:14 UTC