Re: Comments on VERSION-CONTROL

   From: Tim_Ellison@uk.ibm.com

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

Yes, this was added when a reviewer asked for a response that would
tell them whether or not the VERSION-CONTROL request was ignored
because the resource was under version control already.  This is
clearly confusing, so I agree with Tim's suggestion that we just drop
the requirement that the method return this information.  Anyone
object?

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

I didn't quite follow your point here Tim ... could you restate
or clarify?

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

The "value" of an empty DAV:auto-version property is well defined
(it has none) ... do you mean "the behavior of an empty DAV:auto-version
property"?  If the protocol doesn't specify it's behavior, then from
an interoperable clients perspective, it has no behavior.  This
is true for all aspects of the protocol.

Cheers,
Geoff

Received on Sunday, 4 February 2001 22:27:29 UTC