Next message: Geoffrey M. Clemm: "Re: Versioning Conf Call 5/8/2000 - Unreserved checkout flag for activities"
Date: Fri, 12 May 2000 00:58:43 -0400 (EDT)
Message-Id: <200005120458.AAA26319@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: draft-ietf-deltav04.5 now available
From: Chris Kaler <ckaler@microsoft.com>
Here are some comments from my reading of 4.5:
- 2.1: Don't we use the VERSION method to make a rsource
versioned?
Yes, but in its current state, 2.1 is more about the concepts than
about how the functions are marshalled, but it certainly would
be easy to add explict references to the method names.
- 2.3: I think we should make this section more clear. I
think there is a point we want to make, but I think that
people who didn't live through this "discussion" won't
get it.
I agree. Also, following Tim's suggestion, I will move this
information to section 5 in a section on the LOCK request.
- 3.3: I don't think we should do this -- it will impact
down-level clients by seeing a type they don't understand.
We should add a new property to indicate it is versioned.
A versioned resource is only seen by a client if it explicitly
specifies "versioned-resource" in a Target-Selector header
(otherwise it sees a revision or a working resource).
So a down-level client will never see a resource whose type
is DAV:versioned-resource
- 3.3.2: you are missing hyphens in the ELEMENT definition.
Done.
- 3.3.4: It isn't "linear" -- it is exclusive/non-exclusive
or reserved/un-reserved that we are talking about.
I think DAV:linear is still useful (if you don't want to
allow any branching), but this is different from exclusive/
non-exclusive (which doesn't prevent branching).
- 3.3.4: Servers must be allowed to fail changes to this
property if there is a general server policy that would be
violated.
That's true for most things, isn't it (e.g. DAV:auto-version)?
- 3.4.3: I wish we could separate the linear successor from
the merge successors.
- 3.4.4: See 3.4.3
- 3.5.2: See 3.4.3
You can determine which is the successor on "the same branch"
(if any) by seeing which successor has the same DAV:activity.
Similarly for seeing which predecessor is on the same branch.
- 4.1: I hope "label" doesn't include workspaces -- I'd prefer
to see them separate.
In 04.5, they do include workspaces, but keeping them separate is
OK with me.
- 4.1: I don't get the use of "none" -- seems wrong as a "target"
modifier -- send this request nowhere? :-)
We can just fold this into the SET-TARGET request body, if you don't
like it as a header value.
- GENERAL: The examples should be more realistic (better headers, etc.)
Tim is preparing a detailed "scenarios" document, in which we'll
have realistic examples. So I think "minimalistic" examples in
the core spec are OK.
- 5.4.1: We need to include the new methods, e.g., VERSION.
Will do. I assume you mean in a Public response header?
- 6.1: It seems wrong to be able to make a resource versioned if
someone else has an exclusive lock on it.
The VERSION request does not change the body or dead properties of a
resource, but I suppose you could make the case that it causes the
request URL to be associated with a different resource, although to a
versioning unaware client, it doesn't look like a different resource.
- 6.1: Didn't we use to have a depth header on the VERSION method?
We could, but then we need to decide if the semantics are "best effort"
or "only if you can do them all". I'd probably be inclined to just have
this be a GUI operation, and have the protocol just be one resource
at a time.
- 6.2.1: I would prefer to see this be a separate method.
OK.
Also, if
this sepecifies a label, we should allow a depth header.
Then we'd have to decide if an attempt to label a non-versioned
resource (for example, if the collection is not versioned) is an
error or just ignored. In the non-depth case, it would be an error.
- 6.2.2: Removing a label? How? Seems wrong to use a "none" target
OK, we can move that into the body of the SET-LABEL-TARGET request.
- 6.2.2: We should allow a depth header on setting labels.
This is a similar issue to "depth VERSION". We could just say that
this is a GUI operation, and keep the protocol simpler.
- 6.3: It seems wrong to allow a checkout of an exclusively locked
item. Some clients may not be able to deal with this and the
changes will be lost. We should at least have an option to fail
if locked, maybe?
How would clients not be able to deal with this, and how would changes
be lost? It is true that you won't be able to checkin your changes if
it is exclusively locked, but a client that cares about this can just
ask for its own exclusive lock before checking out.
- 6.3: See previous comment about DAV:linear.
DAV:linear applies to core versioning, while exclusive checkouts
apply to advanced versioning (since the exclusive checkout is against
a particular activity).
- 6.3: We should have a body for the request... to allow the user
to indicate reserved/unreserved, etc.
E.g. a DAV:checkout element?
- 6.4: We should have a DAV:checkout tag that wraps the body so that
we can more easily add new tags.
I assume you mean a DAV:checkin element? (6.4 is on CHECKIN)
- 6.5: What does it mean to delete a working resource? Is this an
"UNCHECKOUT"?
6.5 is the UNCHECKOUT method definition, but an UNCHECKOUT both deletes the
working resource, and updates the DAV:working-resource-id-set on the
appropriate versioned resource and revision.
- 6.6.2: This doesn't feel like it should be required for core? Is
it optional?
No, it's required. It's a very simple recursive routine (probably 10
lines or so), and it's what gives us our general history reporting
capability. It's fine for a particular implementation to provide some
specialized forms of this report that it optimizes, but I think a more
generalized report that is universally available is essential.
- 7.1: In reading this it is really wierd to make a workspace a
versioned resource. I understand the desire to re-use concepts,
but it is strange that I "checkout" a revision of a versioned
resource and get a versioned resource not a working resource.
You do get a working resource. It's like a normal resource such
as an html document. You start with a "versionable" html document,
and after you put it under version control, you can check it out to
get a new "working" html document. You can then check that in to
get a new "revision" of that html document.
Analogously, you start with a "versionable" workspace, and after you
put it under version control, you can check it out to get a new
"working" workspace. You can then check that in to get a new
"revision" of that workspace.
Note though that you usually would use the "DAV:keep-checked-out"
flag when you CHECKIN a workspace, so that you can continue to use
the same workspace.
I think we should separate Workspaces and Baselines to use different
methods so that the concepts are separate.
Why? A baseline is just a "revision" of a workspace, i.e. it has
predecessors, successors, and is suitable for merging.
- 7.1: Geoff had asked that we think about whether or not it makes
sense to think of activities as branches. I believe they are
separate. I can evision branches w/o activities as well as a
branch with interlaced activities. I think we should keep these
concepts separate.
What significant benefit would we receive from such a separation? It
does significantly increase the complexity from a clients perspective
to have to deal with this interlacing.
- 8.1: Why wouldn't you initially populate the workspace with
SET-TARGET?
Initially, it doesn't matter, since a MERGE and a SET-TARGET is
equivalent on an empty workspace, but for subsequent requests,
a SET-TARGET will wipe out any existing work from that workspace,
and is therefore less likely to be what the user will want to do.
So it seems simpler to just say that you normally MERGE revisions
into a workspace. But I'm happy either way.
- 8.1: Last paragraph: I think this is very complex to require all
advanced servers to support these semantics.
This is the "request workspace" paragraph? We've pretty much said
from the beginning that advanced versioning servers will use
a default workspace to determine the default target. How is this
complex?
- 8.3: I have a problem with sever merging... I think it is OK for
us to have a method to indicate a client-side merge, but having
the server do merges takes us to a complex place.
How is it complex? If a server is going to support merging at all,
it needs to determine whether two revisions are on the same line of
descent. To say that if they are not, that it creates a working
resource with the appropriate predecessors seems both very useful,
simple to implement, and straightforward for a client to use.
How can a client
discover what has been merged?
From the DAV:update-set in the response body of a MERGE request.
What if the client doesn't want
the server to do any merge?
Then it asks for a DAV:conflicts report, rather than a MERGE request.
I think the MERGE method should be
meta-data only -- not content.
The DAV:merge-state allows the server to say whether it has done
anything to the content or not. So a server that believes that there
should be no server-side content merging would just always return
DAV:initial as the merge state.
- 8.3: Can SET-TARGET cause merge conflicts? This space can be
very messy to do in a fully interopable way.
A merge conflict can only occur as part of a MERGE request, so
SET-TARGET can never cause a merge conflict.
- 8.5: I'm not sure what is meant by a "versioned collection".
Each revision of a versioned collection is a set of bindings and
properties (as detailed by the bindings protocol).
Does changing the contents create a new version?
If by "contents", you mean the set of bindings owned by that collection,
then yes. Normally, I wouldn't use the term "contents" to refer to the
set of bindings, since some people use the term to mean some server
defined default contents such as an index.html file.
If so, then I think
we need to consider an intermediate level. That is, I should be
able to have a "versioned collection" that tracks its properties
and changes to them, but not necesarrily its children.
If you mean that a change to the state of one of its children should
not change the state of the versioned collection, then I agree.
The state of a versioned collection tracks what resources are
the (immediate) members of the collection, but does not track
the states of those resources.
So:
DELETE /a/x.html
modifies the state of /a/, (it no longer has a binding named "x.html"), but
PUT /a/x.html
does not.
- 9.1.1: Why is this in advanced and not core?
It is in core as well. It was just repeated in advanced because of the
"unification" of labels and workspaces. If we follow your suggestion
and keep labels and workspaces separate, then we wouldn't need 9.1.1
- 9.2.2: See previous comment re: merge
Many servers do provide server-side merging support for a variety of
resource types. This property is all that is required to allow a server
to communicate back to the client as to whether it has provided any
such support, so I believe it provides significant value at minimal
cost in complexity.
- 9.3.2: We talked about removing this last week?
Yup. It'll be gone in the next revision.
- 9.3.7: I'm not sure I understand what this property is for...
This provides a way for a client to enumerate the workspaces that
are expected to periodically MERGE their work to this workspace.
It provides some minimal interoperable support for "change flow".
- 9.4.2: I think this needs to be optional -- I can see server
supporting activities, but this is more complex.
The only semantics here is that when you do a MERGE on an activity, it
invokes a MERGE on all its DAV:needed-activity-set as well. This
seems pretty innocuous, but I'm happy to get rid of this property, if
nobody wants to champion it.
- 10.1: Why don't we fold this header into Target-Selector?
Target-Selector only applies to the request-URL. The Workspace applies
to all versioned resources encountered in the request (primarily used
to deal with versioned collections). This separation allows a
core-versioning client to interoperate with an advanced versioning
server that supports versioned collections.
- 12.3: It isn't clear how I merge between two workspaces.
You take a revision, baseline, or activity produced in one workspace,
and merge it into the other workspace. You can also just name
the source workspace in the request-URL, and that will merge every
revision in the source workspace into the destination workspace
(named in the Workspace header).
- 13.1: I don't think I understand what this report is for? Is
it required or optional?
This lets you find out what the default workspace is for a URL.
It is required, but it can return an empty element if there is no
default workspace for that URL.
- 13.2: Can this report be optional?
This seems like a reasonable thing to require that a server provide.
For some servers, this will just be some server-defined munging of
the stable URL. For others, it will require scanning over the
versioned resources in the workspace, but in either case, it is
far more efficient for the server to do it.
- 13.3: Shouldn't this be just like the MERGE method in terms of
the data that can be passed?
The input is the same, but the output is different because the
MERGE method can just create the appropriate set of working resources
whose DAV:predecessors indicate the contributors, while the conflicts
report needs to capture this contributor list as an XML report.
- 13.3: Can this report be optional?
Yes, it would only be supported by a server that supports the MERGE method.
- 13.4: Can this report be optional?
Sure.
- 13.5.1: I think we should clean up the XML. For example, in
the response, I would think something more like:
<D:repository-report>
<D:activity>
<D:href>...</D:href>
</D:activity>
</D:repository-report>
so that you can request multiple items.
Sounds reasonable to me (I think Tim suggested this as well).
Cheers,
Geoff