RE: Version-controlled collection resources - I am still missing something

"Clemm, Geoff" <gclemm@rational.com> wrote:
> ...
> So following text should have appeared in section 14.9
> (additional VERSION-CONTROL semantics for version-controlled
> collections):
>
>  Additional Postconditions:
>
>  (DAV:new-version-controlled-collection): If the request
> body identified a collection version, the collection at
> the request-URL MUST contain a version-controlled internal
> member for each DAV:version-controlled-binding specified
> in the DAV:version-controlled-binding-set of the collection
> version, where the name and DAV:version-history of the
> internal member MUST be the DAV:binding-name and the
> DAV:version-history specified by the
> DAV:version-controlled-binding.  If the internal member
> is a member of a workspace, and there is another member of
> the workspace for the same version history, the
> DAV:version of the internal member MUST be the DAV:version
> of that other member; otherwise, the DAV:version MUST be
>  the DAV:root-version of the version history.
>
> If nobody has any objections to this text, I'll add this to
> the next working draft.

I guess that picking the DAV:root-version is the obvious choice from a
protocol-writer's perspective since it is well defined in the spec.  It
also provides behavior that is predictable by the client since they know
the root version.  However, it would seem to me that clients would 99.9% of
the time have to UPDATE / MERGE all of the version-controlled resources
created using this rule.

How do you feel about making the new version-controlled resources have a
DAV:checked-in of the (chronologically) latest version instead?
I have no great desire for this, but just think it may be more client
friendly.

Regards,
Tim

Received on Wednesday, 4 July 2001 06:15:05 UTC