Re: Versioning spec review - 02.3
Bradley Sergeant (Bradley.Sergeant@merant.com)
Wed, 20 Oct 1999 12:12:49 -0700
Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF53438BF@BEAVMAIL>
From: Bradley Sergeant <Bradley.Sergeant@merant.com>
To: ietf-dav-versioning@w3.org
Date: Wed, 20 Oct 1999 12:12:49 -0700
Subject: RE: Versioning spec review - 02.3
See if you can parse <sarge2> below.
-Sarge2
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Wednesday, October 20, 1999 6:46 AM
To: ietf-dav-versioning@w3.org
Subject: RE: Versioning spec review - 02.3
<sarge>
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?
</sarge>
<jra>
I think this mapping is up to the server and is part of its implementation.
I don't think it needs to be specified in the protocol. The purpose for
having the workspaces is to know what what workspace the revision is
checked out in. That's what you need to know to get the working resource.
</jra>
<sarge2>
I don't think we are communicating. All I'm saying is that as a client I
want to be able to obtain the URI of the working resource. In the current
spec I see no way to do this. This seems wrong to me.
</sarge2>
<sarge>
OPINION: If we are allowing generalized property assignment as part of
CHECKOUT and/or CHECKIN then using D:propertyupdate and D:propstat seem
justified. However, if we are only passing method specific arguments to,
and results from these methods then perhaps we should use new XML elements
with specific semantics.
</sarge>
<jra>
Agree completely. I think using propertyupdate is an unnecessary protocol
optimization that creates overlap between methods and extra rules.
</jra>
<sarge>
Seems to me that 6.2 should at least mention the affect of DAV:overwrite on
mutable revisions. It's a little too subtle to leave it to the
DAV:checkin-policy property definition to provide this information.
</sarge>
<jra>
Yes, I thought this was missing too, but didn't notice it in my first pass.
</jra>
<sarge>
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?
</sarge>
<jra>
I think we should add this. The information will be useful for determining
the quality of merge operations. It also provides a very simple way for
DMS servers to support immutable revisions.
</jra>
<sarge>
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...
</sarge>
<jra>
I don't think a lock should be a checkout. See the note I sent out on
locking semantics.
</jra>
<sarge2>
I saw your note, but this was just put on the issues list as something to
discuss. I'm saying that the current spec has a hole in it. Perhaps we'll
decide to fix it your way, but regardless it needs to be changed so that you
can issue a lock on a working resource. I'd like Geoff to respond as to
whether there is a way to lock a working resource given the current spec.
I've suggested it could be done with the URI of the working resource, but as
I've said, I don't see how to get at this URI in the protocol.
</sarge2>
<jra>
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. 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. 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.
</sarge>
<jra>
Can't this requirement be met with BIND? This doesn't seem like a versioning
issue. Given multiple bindings to the same resource, different workspaces
can pick up different revisions of the bindings giving different views
of the same versioned resources. So I think we still have the functionality,
and its more flexible than before.
</jra>
<sarge2>
So you're saying we can use advanced collections to restructure a versioned
resource tree and achieve the same thing. Perhaps this will work, but I
don't think so. My concern is that it means you have to have one primary
structure for your versioned resources which you can never delete or
restructure because you've got bindings that reference it. It's one thing
to say that the history resource URI (which the server generates) must not
change, but saying that a publicly used versioned resource URI (that the
user invents) can't change I see as a big problem. My experience in this
area tells me that we need an invariant URI or ID of some sort that allows
you to always get at the same revision graph. I don't think the versioned
resource itself can play this role because the client needs/wants to be able
to move and delete these items for specific project needs, without affecting
other structures used for other purposes that reference the same revision
graphs. See the point?
As I've posted in earlier mail on this topic, I'd rather see:
* the revision reference the working resources,
* the working resources reference the workspace (which they do) and
also the associated versioned resource (which they don't),
* the workspace reference the working resource (which they don't).
I don't want:
* the revision referencing the versioned resource (which it currently
does),
* the workspace referencing the versioned resource (which it currently
does). I'd rather let the client go to the working resource to get this
information if required.
That is the model I think works best, but it requires a history resource, or
a two level lookup on a repository resource. We had the history resource
before, but it suddenly vanished.
</sarge2>
<sarge>
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.
</sarge>
<jra>
I didn't think the RSR was required. The spec distinguishes simple and
extended workspaces. Simple workspaces don't have an RSR, so they can
only be used to access checked out resources. The purpose of this is
to allow client applications to manage their "workspaces" locally
without server involvement.
</jra>
<sarge2>
The RSR property is part of the CORE. The spec talks about Basic and
Extended Workspaces, but does not indicate the Extended Workspace is
optional for a server. I get the feeling we are in fact trying to support
servers and clients that do not know about RSRs (i.e. only use Basic
Workspaces). I just think this needs to be more clearly explained and
motivated.
</sarge2>