Re: Why have separate DAV:checked-in and DAV:checked-out?

Peter Raymond <Peter.Raymond@merant.com> wrote:

> Hi,
>
> I was thinking about the issue of properties being removed
> or empty depending on the state of the resource and the
> effect this has on PROPFIND and supported-property-set
> etc.  It struck me as odd that the protocol defines
> DAV:checked-in and DAV:checked-out as two separate
> properties, rather than having one property to identify
> the version and another to identify the state (eg is it
> checked-in or checked-out). I would have thought something
> like the following would be more logical, this way the
> properties are always present:
>
> 3.2.1DAV:version (protected)
>
> This property appears on a version-controlled resource,
> and identifies a version that has the same content and
> dead properties as the version-controlled resource.
>
> <!ELEMENT version (href)>

Well, it has the same content and dead properties as a checked-in
version-controlled resource, since when the version-controlled resource is
checked-out the content and dead proeprties can be modified.  So the
description you gave would have to be conditional, or state that the
checked-out version-controlled resource was based on...

> 3.2.2DAV:status (protected)
>
> This property appears on a version-controlled resource,
> and identifies the state of that resource (checked-in
> or checked-out).  This property is changed when the resource
> is checked out or checked-in.
>
> <!ELEMENT status ANY>
> ANY value: A single element which can be either a
> DAV:checked-in element or a DAV:checked-out element.
>
> <!ELEMENT checked-in EMPTY>
> <!ELEMENT checked-out EMPTY>

This would require retrieving the property and parsing it to determine the
checked-in status rather than using the PROPFIND propname construct -- a
minor distinction I grant you.

> Is there a good reason why the above is not desirable or
> why the current behaviour is better?

I'd be a bit concerned that the description for DAV:version would be
complex since it's meaning would be dependent upon the value in DAV:status.
I also thought that separate properties would allow an expand property
report to naturally terminate if the property is missing -- but have no use
case to back it up.

Regards,
Tim

Received on Monday, 20 August 2001 05:09:31 UTC