RE: Using PROPPATCH to create a resource with no body

I think overloading PROPPATCH so it can also create resources is a
sub-optimal design choice.

> A common issue for each of these new resource types is how one creates
> an instance.  The approach started by the core WebDAV spec is
> to introduce a new method for creating each new resource type
> (e.g. MKCOL). This becomes rather burdensome when
> the list starts growing (MKWORKSPACE, MKACTIVITY, MKCONFIGURATION,
> MKHISTORY, ...), and is rather redundant since they all take the
> form of initializing a set of properties of a new resource.

On the plus side, if I'm looking to create a workspace, and I'm glancing
through the table of contents of the Delta-V specification, I'll immediately
guess that MKWORKSPACE does the job.  In contrast, it would take some
reading, and some head scratching to figure out that PROPPATCH did this as a
side effect.

> An alternative approach is to just allow PROPPATCH to create a new
> resource when it is applied to a null resource.  I would propose
> also adding a new value for the Overwrite header, e.g. Update,
> which would say that the destination of operation should be updated,
> rather than deleted (Overwrite=T) or have the operation fail
> (Overwrite=F).
> Then the Overwrite header could be used to control the effect of a
> PROPPATCH.
>
> This is very consistent with the functionality of PUT, which can be
> used either to update an existing resource or create a new resource.

Right, but PUT was explicitly designed to be a resource creation method,
PROPPATCH was not.

> Another alternative is to introduce a MKRESOURCE method, which would
> be equivalent to a PROPATCH with Overwrite=F.

I like this idea the best.  In particular, the current defintion of
MKRESOURCE uses the value of the resourcetype property to determine the kind
of resource that is created (workspace, etc.).  This is a different behavior
than when the same property is operated on using PROPPATCH (normally,
resourcetype is read-only).  Since MKRESOURCE is affecting the semantics of
the property set operation, it doesn't seem like a good separation of
concerns to try and shoehorn this functionality back into PROPPATCH.

Since MKRESOURCE does have different semantics than PROPPATCH, and since I
have yet to see any critique giving reasons for why MKRERSOURCE is a bad
design choice, simple separation of concerns leads me to favor MKRESOURCE
over an overloaded PROPPATCH.

- Jim

Received on Monday, 16 August 1999 18:24:52 UTC