WebDAV vs HTTP method semantics

Mike Dierken mike@DataChannel.com
Mon, 27 Aug 2001 13:07:24 -0700


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12F33.E37F1A80
Content-Type: text/plain;
	charset="iso-8859-1"


> > I believe MOVE would simply be COPY+DELETE, aka GET+PUT+DELETE.
> 
> Think of it another way.  The URI namespace consists of a hierarchy
> of names (collections).  COPY and MOVE semantics are not really operations
> on the target of the COPY and MOVE -- in fact, they are operations on the
> parent collections that "own" the origin and destination namespaces.
> The set of names within a collection are the state of that collection
> as a resource.  

Well put. Modelling these as acting on collections is very powerful, and in
my view, correct.

I used this in some recent work with events. I defined a small set of six
operations - create, read, update, delete, add and remove. The 'add' and
'remove' really only apply to collections. It took a little bit of effort,
but not much, to describe the difference between 'create' and 'add'.

I also defined an aspect of the event called 'property' - a sub-property of
some object - and that has been extremely hard to communicate. This gets
into the realm of 'resource modelling' that isn't often done.

mike

------_=_NextPart_001_01C12F33.E37F1A80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">



RE: WebDAV vs HTTP method semantics



> > I believe MOVE would simply be COPY+DELETE, = aka GET+PUT+DELETE.
>
> Think of it another way.  The URI = namespace consists of a hierarchy
> of names (collections).  COPY and MOVE = semantics are not really operations
> on the target of the COPY and MOVE -- in fact, = they are operations on the
> parent collections that "own" the = origin and destination namespaces.
> The set of names within a collection are the = state of that collection
> as a resource. 

Well put. Modelling these as acting on collections is = very powerful, and in my view, correct.

I used this in some recent work with events. I = defined a small set of six operations - create, read, update, delete, = add and remove. The 'add' and 'remove' really only apply to = collections. It took a little bit of effort, but not much, to describe = the difference between 'create' and 'add'.

I also defined an aspect of the event called = 'property' - a sub-property of some object - and that has been = extremely hard to communicate. This gets into the realm of 'resource = modelling' that isn't often done.

mike

------_=_NextPart_001_01C12F33.E37F1A80--