Subject: Using PROPPATCH to create a resource with no body

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Mon, 16 Aug 1999 13:53:54 -0400

The DeltaV versioning extensions to WebDAV propose four new
types of resources: workspace, activity, configuration, and history.

All these new resource types share the characteristic that their
state is represented as a set of properties, rather than in a body.
In this way, they are like the collection resource type from the
core WebDAV protocol, and the redirect-reference resource type from
the advanced collection WebDAV extensions.

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.

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.

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

I personally favor extending PROPPATCH since it is both more consistent
with PUT, and a more powerful/flexible approach.  As a note, MKCOL would
then just become an alias for a PROPATCH, with the resourcetype
property set to be <D:collection/>

Comments?

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 16 Aug 1999 15:19:02 -0700

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

> 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.

> 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.

> 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