Re: Versioning spec review - 02.3

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Wed, 27 Oct 1999 01:22:29 -0400 

Date: Wed, 27 Oct 1999 01:22:29 -0400
Message-Id: <9910270522.AA25916@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <85256816.0049881A.00@d54mta03.raleigh.ibm.com>
Subject: Re: Versioning spec review - 02.3

   From: jamsden@us.ibm.com

   <jra>
   We went to a lot of trouble trying to establish levels only to eliminate
   the concept in Concord. It seems too bad to reintroduce them now. I hope we
   don't go over that same ground again. I wasn't helpful getting the
   versioning semantics down.
   </jra>

I assume you meant "It wasn't helpful ..." (:-).
I believe the reasons why levels are preferable to options still are valid.
If the protocol now displays some natural leveling after recent iterations,
I think it is important that we recognize and take advantage of it.

   <jra>
   ... we need to say that the server can fail the operation or
   overwrite the revision. I don't remember seeing this in the postconditions
   of CHECKIN.
   </jra>

The postconditions are the state you reach after successful completion
of the operation.  If the operation is aborted, then the postconditions
will not hold.  This is true for all the postconditions, not just the
DAV:overwrite one.

   <jra>
   So baselines don't have human meaningful names or labels? How will a user
   distinguish one fron another?
   </jra>

A client is free to give them various properties to identify them.
We could standardize on some of these, but I tend to dislike enumerating
dead properties (even interesting ones) in the protocol.  Perhaps
we could have some companion document (and move DAV:comment and DAV:author
into it)?

   So you now just create baselines with the MKRESOURCE
   command.  There's a ToDo note in the draft saying this should be explicitly
   mentioned in the MKRESOURCE method description.

   <jra>
   I don't recall MKRESOURCE mentioning creating baselines, or the semantics
   of how one was created.

That's why it's a "ToDo" note (:-).

   Does the collection have to be checked in? Can it
   have working resources in this or any other workspace?

That's in the issues list (I vote: "collection has to be checked in",
"cannot contain working resources in this workspace", "doesn't matter
what is in other workspaces").

   How is the baseline
   identified or distinguished from another baseline?

By its URL.

   Baselines and revisions are indicated in RSR's by their URL's.  We
   could allow alternative compound notations as well, but is there
   a compelling reason to do so (it does add complexity).

   <jra>
   So the human meaningful name (its human URL and revision id) for a revision
   can't be used in the RSR?

That's my vote.  As fun as RSR's are (:-), I see them as a client artifact,
not a user artifact.

   If we had a method for setting the RSR, the
   server could  translate human names into revision URLs and back.

I think clients are good at doing whatever name translation is needed,
and PROPPATCH does a good job of setting the RSR property of a workspace.

   I had no trouble specifying the appropriate constraints on the
   appropriate properties in the protocol.  Live properties commonly have
   their values constrained by the server, so this is nothing unusual for
   WebDAV.

   <jra>
   Its not just the properties you're describing, its the use of the PROPPATCH
   and BIND methods too. For example, adding a revision to a configuration
   with BIND. BIND has a set of semantics of its own, but binding a revision
   to a configuration has more semantics.

Nothing beyond the description of what kinds of objects are legal in
that collection.

   <jra>
   If you have a bunch of versioned collections in a
   hierarchy, and you want to access a specific revision of a member of one of
   them, then you need two things: the workspace to use to select the righ
   revisions of versioned collections along the path, and a revision name to
   select the specific revision of the member versioned resource. We don't
   want to require users to us repository and server implemented URLs for
   this.
   </jra>

You use a PROPFIND with the workspace as the target selector to get
the DAV:revisions property of the DAV:versioned-resource property of
the revision.  With the DAV:revisions collection, you can select any
revision of that versioned resource that you want.

   The DAV:revision-labels collection is there to give clients easy access
   to any revision by using a label.  No need for a specific header, and
   suitable for use in any context where a URL can be specified (as opposed
   to the Target-Selector, which just works for a Request-URL).

   <jra>
   It is not acceptible to require clients to translate URL and revision names
   into server generated revision URLs for this operation. The client should
   always be able to use the name they know a revision by to access that
   revision.
   </jra>

I'm not sure what you mean by "translate URL and revision names into
server generated revision URL's".  If you mean, concatenate the
DAV:labeled-revisions URL with a "/" and a label, then I find that
totally acceptable.  That's exactly what a client does for a user whenever
a specific member of a collection is requested.

   <jra>
   CHECKOUT creates a working resource that is a copy
   of the checked out revision, there is no need to "initialize" it any
   further. ...

I don't really feel strongly about this one way or the other, so I'll
skip over this issue.  I'll skip over the "UNCHECKOUT as a variant of
CHECKIN" issue for the same reason (:-).

Cheers,
Geoff