Re: Versioning spec review - 02.3
jamsden@us.ibm.com
Wed, 20 Oct 1999 09:45:52 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256810.004BBE00.00@d54mta03.raleigh.ibm.com>
Date: Wed, 20 Oct 1999 09:45:52 -0400
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>
<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>
<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>
<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>