Resource type (was RE: AW: Removing the DAV:activity and DAV:version-history and DAV:baseline resource type values)

Lisa wrote:
> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: 06 June 2001 17:00
> To: Tim_Ellison@uk.ibm.com; DeltaV (E-mail)
> Subject: RE: AW: Removing the DAV:activity and DAV:version-history and
> DAV:baseline resource type values
>
>
> Tim said:
> > So, if we are to continue this use of DAV:resourcetype it would
> > be to give clients a useful classification of a resource at a
> > particular point in time that would give them a reasonable set
> > of data for displaying an icon, greying menu items and so on.
> > It should convey both versioning 'type' and 'state' that is
> > within the mandate of WebDAV.  The specification has already
> > called out a number of useful resource classifications and they
> > are the ones that I proposed (DAV:checked-in _and_ DAV:checked-out
> > may be redundant).
>
> In common usage, "type" is somewhere else along the range of persistence
> from "state".  A couple thoughts on how you can tell the difference:
>
>  - When things can change state, it's because they're supposed to,
> so we give a way to check out something that's checked in and vice
> versa.  WebDAV does NOT give a way to turn a collection into a
> regular resource -- clients have to _remove_ the resource --
> completely taking away its existence -- and replace it with a
> resource of a different type.

I'm surprised that you say this.  WebDAV gives me PROPPATCH.
Say I had a server that allowed clients to PROPPATCH the DAV:resourcetype
property.  Why would that not be DAV compliant?
Imagine the client does a PUT to create a resource, sets some dead
properties and so on, maybe even LOCKs it.  Then they decide that they are
going to restructure the resources, and convert that resource into a
collection.  The client simply PROPATCHes DAV:resourcetype, adding
<DAV:collection/>, to flag it as a resource capable of storing a "list of
internal member URIs".  GET still works as before, PROPFIND still works as
before, etc.  I don't recall seeing anything that said I have to delete the
resource first.

RFC2518 provides MKCOL for creating a resource as a collection.  This is
fine and obviously very useful as a means to create a resource (with no
content) and set a specific property (DAV:resourcetype) simultaneously.
However, I hazard to guess that what most people would wish for is a method
that allows simultaneous atomic creation of content and numerous properties
in the same method.  (Of course we'd debate such a beast for so long ...).

DeltaV went through a phase of using MKRESOURCE to create all the different
resources and ended up falling in line with MKCOL for numerous reasons.

So my question is, does WebDAV disallow <DAV:collection/> being a "state"
that I can change on a whim? (assuming no internal members are being left
orphaned)

> The only sense in which that operation "changes the type" of a
> collection is that it is an entity that shares the same name as
> the previous entity -- but no other continuity.

That's one view of the world.  I don't hold that view and I think that
RFC2518 permits both so that's cool.

> DeltaV _does_ blur the line by adding a VERSION-CONTROL method
> to turn a regular resource into a VCR, however, this method performs
> drastic surgery, with the side effect of up to three resources
> being created.

But if you step into my shoes for a moment, and think of the transformation
simply as a PROPPATCH with some set and remove elements the transformation
may not seem so drastic (obviously it is the server changing the properties
of the resource so it isn't actually akin to a PROPPATCH).

The regular resource -> version-contolled resource transformation is, to me,
setting up the resource so that the server treats it differently with
respect to HTTP methods.  It is still the same resource (retains its dead
properties, locks are unaffected, binding refs to it remain intact etc.).
However, if you think of the transformation as having to 'replace' the
resource (i.e. by sequences of DELETE, LOCK, PUT/MKCOL, PROPATCH, BIND) then
it does require lots of server effort to recreate a substantially equivalent
resource state.  Isn't PROPPATCH simpler?

> Many servers will only support version-controlled resources, and
> thus not allow the transformation in either direction.

Agreed.  And many servers will not support LOCKing for that matter :-)

>  - States are used as adjectives.   A "checked-out version-controlled
> resource" isn't a type, it's a type with a state modifier.  I think
> intuitively we use the language correctly:  we abbreviate VCR, VR, and VHR
> to define different types of resources, but we don't through the state
> adjectives in to have COVCR and CIVCR.

Abbreviations aside, the specification DOES refer to "checked-out
version-controlled resources" on many occasions since it is an important
resource state, err type, err whatever.

>  - State changes more frequently than type.  A typical VCR will have its
> checked-in and checked-out state change MUCH more frequently than
> its type.

Agreed that this is typically the case.

> I understand that this is one of many situations where there is
> not a clear, fine line between two things.  You can certainly blur
> the distinction if you choose by attacking any one of my arguments,
> or all.

Hopefully you do not see this as attacking your arguments.  I understand
your position and that works too.  I offered an alternate view which you are
free to debunk.

> That does not prove that we should clump them together.  Humans
> are capable of fuzzy distinctions, and these are useful to us,
> even if not to the software we write.

In the spec and in software we do need to be clear.

> My argument is to apply common notions to decide what different
> types need to be called out in resourcetype.  IMHO,
> checked-in/checked-out is a state, not a type.

Whether I agree with checked-in/checked-out being a state or type (I happen
to think of it as a state too), I'm claiming that there is no reason why
DAV:resourcetype cannot contain both (despite its name), and that the only
recognized value today <DAV:collection/> can be viewed as either a state or
type anyway.

Tim

Received on Thursday, 7 June 2001 07:03:58 UTC