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

There is no defined interaction between VERSION-CONTROL and the Depth:
header (if that's what you meant).

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

Good point, stating that the request is ignored but produces a prescribed
response seems counterintuative.

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

This was my understanding

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

Firstly, I'm unsure why we need to respond with
<DAV:version-control></DAV:already-version-controlled></DAV:version-control>,

I'd be happy to drop this from the protocol.

Secondly, I agree that there are a number of places where the marshaling is
underspecified with respect to (usually) error conditions (though in this
case it is a 200 OK response).
For example, in REPORT "the response body MUST contain the requested
report" and "The DAV:version-tree REPORT response body MUST be a
DAV:multistatus XML element."

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

This is described in the semantics section and in the postconditions for
VERSION-CONTROL.  Maybe calling out DAV:checked-in explicitly here was
unfair.

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

It would be implementation dependent as per Section 1.5.1.

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

The DAV:auto-version property MUST be present.
"All methods, properties, and behaviour defined in core versioning MUST be
supported by a versioning server."
If the property value is empty then auto-versioning will not occur.  If the
value is one of the given values then the behavior is defined, if the value
is an undefined value then the behavior is undefined.

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

Empty means no auto-versioning occurs.

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

Agreed.  A quick check reveals that this is the only property value
declared as ANY.

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

The DAV:predecessor-set is initialized to be the href of the checked-out
version.

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

This is covered by the definitions of those resources (i.e., that they have
those properties and how they are initialized), it would be redundant to
restate it here.

Tim

Received on Friday, 2 February 2001 05:33:20 UTC