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.  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.
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.  Many servers
will only support version-controlled resources, and thus not allow the
transformation in either direction.

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

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

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

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.

lisa

Received on Wednesday, 6 June 2001 12:02:05 UTC