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

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


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>


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

Regards,
Peter Raymond - MERANT.

Received on Sunday, 19 August 2001 08:24:49 UTC