Re: Versioning spec review - 02.3

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Mon, 25 Oct 1999 18:31:53 -0400 

Date: Mon, 25 Oct 1999 18:31:53 -0400
Message-Id: <9910252231.AA24983@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <F3B2A0DB2FC1D211A511006097FFDDF53438BD@BEAVMAIL> (message from
Subject: Re: Versioning spec review - 02.3

   From: Bradley Sergeant <Bradley.Sergeant@merant.com>

   QUESTIONS: Given the URIs for a versioned resource and a workspace how does
   one obtain the URI of the associated working resource. Rather than the
   revision maintaining a list of working-resources you have it maintain the
   associated workspaces instead (DAV:workspaces).  This seems to make it much
   more difficult to get at the working resources of a particular revision.
   What's the reason for the indirection?

The intent was to not force an implementor to have a URL that would
identify a working resource.  This was not thought to be a problem,
since users will be referring to working resources with user-meaningful
URL's and a workspace header, not by some obscure server-generated
URL.  On the other hand, a DAV:working-resources property for a
workspace does give the client a convenient way of getting a report
on *all* working resources in a workspace.  So you'll find that the
most recent spec has added the DAV:working-resources property to
a workspace.  Does anybody have a problem with this?

The omission of DAV:working-resources from a revision was for
a more significant reason, namely to allow workspaces to exist
on different servers from the repositories containing the
versioned resources.  I think this will be very important,
and since cross server bindings are unlikely to be implemented,
I've tried to avoid having any collections where the member
of the collection is likely to be on a different server from
the collection.

   6.1 Marshalling.  The Request-URI specifies the specific revision or the
   versioned resource to be checked out.
   6.2 Marshalling.  The Request-URI specifies the specific working resource or
   the versioned resource to be checked in.
   In either case if the Request-URI specifies a versioned resource the
   Target-Selector (or lack there of) will be determine the revision/working
   resource to act upon.

That makes sense.  Does anybody have a problem with this?

   QUESTION: So the current spec now says that you don't choose to make
   individual revisions mutable or not?  The server is simply at liberty to
   allow overwrites of any revisions or to disallow overwrite of any revisions
   as it sees fit (i.e. no per resource properties indicating mutable/immutable
   state).  Is this correct?

Yes.

   QUESTION: If lock on a versioned resource does a checkout (4.9), then how do
   you lock a working resource?  I know, you use the specific working resource
   URI.  Oh, but how do I get that?  Oh, I already asked that question...

A downlevel LOCK (with no Target-Selector) would both CHECKOUT (into the
default workspace) and LOCK.  A versioning LOCK (with a Target-Selector)
would just do a LOCK.

   CONCERN: Looks like this revision of the spec (2.3) has changed the model so
   that there is now a 1-1 relationship between the version graph and the
   versioned resource.  See 3.4.3 DAV:revisions property of versioned resource
   and 3.5.7 DAV:versioned-resource property of revision.

Yup.  I didn't want to, but Jim Amsden twisted my arm (:-).  To be fair,
he twisted my arm to simplify, and I came up with this way of doing so.
So I'm happy to change it back if we've lost any important functionality
as a result.

   Before version 2.3 of
   this spec the versioned resource was more like JimW's Vportal.  You could
   have multiple versioned resources (Vportals) pointing at the same version
   graph.  This is a feature loss.  I can no longer share the same resource in
   different hierarchies.

You can still do that by binding the versioned resource into any collection
in which you'd like to make it visible, so I don't believe you've lost this
functionality.

   While this makes some server implementations easier,
   it makes some applications impossible.  Example, having both a production
   view of a web site as well as having different hierarchies of the same
   versioned resources can simplify some maintenance tasks and simplify some
   development tasks.  In the SCM world it's call sharing and is very popular.
   Why has this gone?  I'm not sure we can live without it.

I agree all these are important.  I believe we can do all this by just
binding the versioned resource(s) into multiple places (which is what
the BIND protocol is all about).  One of the reasons I've been active
in the advanced collection group is to ensure that this functionality
would be available for use by the versioning group.

   QUESTION/OPINION: If workspaces are requred (and they are in the current
   spec) and the RSR property is required (and it is), then why do we need to
   support version-aware clients that don't grok RSRs?  I guess this is the
   checkout token thing.  I'm not really saying I'm against it.  What I am
   saying is that I think it needs to be explained (and maybe even justified)
   in the spec.

I wouldn't want to spend too much time in the protocol spec on this issue,
since it is a server implementation thing, but I agree a few choice words
would be worthwhile.

Cheers,
Geoff