Comments on VERSION-CONTROL

1) Section 2.4 states:

> If the request-URL identifies a version-controlled resource,
> the request is ignored.  This allows a client to be unaware
> of whether or not a server automatically puts a resource under
> version control when it is created.

This is good -- it allows a client to apply VERSION-CONTROL to an entire
directory without having to first check and see if all resources are under
version control.

But then in the Postconditions section it states:

> (DAV:already-under-version-control): If the request-URL identified
> a resource already under version control at the time of the request,
> the VERSION-CONTROL request MUST NOT change the state of that
> version-controlled resource, and the DAV:checkout-response body MUST
> contain a DAV:already-version-controlled element.

Since it is my understanding that invoking VERSION-CONTROL on a resource
with URL U has the effect of converting the resource at URL U into a
version-controlled resource (as well as creating a new version resource, and
a new version history resource), this appears to contradict the ignore rule
given at the beginning of Section 2.4.  I can see flagging an error if
VERSION-CONTROL is invokved on a version resource, or a version history
resource, so perhaps that was the intent of this postcondition.

Or maybe the intent is that no action will be taken, but a
DAV:already-under-version-control element will be present (with a 200 OK
response code? -- this too is unclear).

2) It was unclear to me why VERSION-CONTROL departed from the standard
convention concerning reporting of postcondition errors by requiring that
the response body begin with a DAV:version-control XML element.  As
described in Section 23.2, the postcondition element is typically reported
with a 403 or 409, and is the first XML element after the <?xml
version="1.0" encoding="utf-8"?> preamble.  This is being changed by
VERSION-CONTROL's requirement that the DAV:version-control element must come
before the DAV:already-version-controlled element.  But, since there is the
additional postcondition of DAV:put-under-version-control, it is also
possible to have a response that doesn't fit the XML specification under
"Marshalling" in Section 2.4 (or at least makes this slightly
underspecified), since there can be an element that doesn't have
DAV:version-control before it.

3) In addition to DAV:checked-in, VERSION-CONTROL MUST also set the values
of other properties on the version-controlled resource, and the version
resource -- more is happening with properties than just setting the value of
DAV:checked-in. Other properties that need to be addressed:

On the version-controlled resource:
DAV:auto-version:
a) It seems to me the server MAY set a default value for this if it supports
auto-versioning. This depends on the meaning of DAV:auto-version not being
present at all, and the meaning of DAV:auto-version being an empty property.
We coudl either require DAV:auto-version to always be present, but it might
be empty, or we could have it not be there, and have that signal no
auto-versioning.

*) This certainly raises the issue that, at present, the value of an empty
DAV:auto-version property is not specified, and should be.

On the version resource:

DAV:version :: The server MUST set the value of this.
DAV:predecessor-set :: The server MUST set the value of this, to empty.
DAV:successor-set :: The server MUST set the value of this, to empty.
DAV:version-name :: The server MUST set the value of this.

*) Additionally, in Section 5.9, the additional semantics should include
adding the version-history specific properties in 5.2 and 5.3 to the
version-controlled resource, and the version resource.

- Jim

Received on Thursday, 1 February 2001 20:22:16 UTC