resource type/state (was: Re: Core versioning issues and nits)

>    From: "Lisa Dusseault" <lisa@xythos.com>
>
>    > > 7) How do you distinguish between:
>    > >  - A versionable resource
>    > >  - A non-versionable resource
>    > >  - A version-controlled resource
>
>    > A versionable resource will answer with (at least) Allow:
>    > VERSION-CONTROL to an OPTIONS request, a non-versionable resource
>    > will not.  A version-controlled resource is the only resource
>    > with a DAV:checked-in or DAV:checked-out property.
>
>    > There was some debate a while ago about making the resource types
>    > explicit, with various methods sugested.  I have to say that
>    > determining type by the presence or absence of properties is
>    > sub-optimal since, among other things, it makes for careful
>    > consideration when defining new resources with overlapping
>    > property names.
>
> One person's "resource type" is another persons "resource state".
> Is "checked-out" a resource type or a resource state?  Is "locked"
> a resource type or a resource state.  Is "under version control"
> a resource type or a resource state. ...

I'm not getting drawn into that one<g>

> So either you need to carefully consider your choice of property
> names (which you should do anyway), or carefully consider your
> choice of "resource type names".

I think the issue comes down to using the presence or absence of a property
to define a resource type (to use the document's terminology), rather than
using a property's value.  Practically, it means issuing a PROPFIND and
discarding some of the response and/or looking for errors.  This feels like
a secondary effect from the definition of those properties (although
clearly it is a primary effect given that clients typically need to know
the resource type).

I say property names should be chosen carefully since extensions may not be
able to use the property names DAV:checked-out and DAV:checked-in without
other properties that distinguish the resource type.

>    I agree that determining type by the absence of properties is
>    sub-optimal; I'd say it's not very reliable.
>
> How is it any less reliable than looking for a particular value
> in a "resourcetype" property?

I agree that Lisa's use of the word "unreliable" is incorrect here, but I'd
say that looking for a property value is more direct and extensible.

Tim

Received on Monday, 5 February 2001 10:45:16 UTC