Re: Versioning spec review - 02.3
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 19 Oct 1999 01:44:03 -0400
Date: Tue, 19 Oct 1999 01:44:03 -0400
Message-Id: <9910190544.AA21458@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <8525680E.007205BD.00@d54mta03.raleigh.ibm.com>
Subject: Re: Versioning spec review - 02.3
Jim: Thanks for the very thorough and very prompt review!!!
From: jamsden@us.ibm.com
Here's my comments on the 02.3 spec:
1.1, 2nd paragraph Versioned Collection versioning -> Versioned Collection
done.
Also, core is described as providing versioning of largely independent
resources. Independent with respect to what? Most web applications are highly
linked resources, so this level of versioning by implication isn't particularly
useful. What exactly is meant by this statement? I think independent in this
case refers at least in part to independent changes in the resources, not
necessarily just independent resources.
Core versioning does not provide baselines, activities, or versioned resources.
Web resources may be highly linked, but core versioning doesn't give you
anything in particular to version control those links.
Last paragraph: How about using components of versioning support instead of
"levels"?
"Components" is so over-used these days, that I hate to add another meaning.
1.2, Versionable Resource: Might want to put what it means to place a null
resource under version control. Does it become a resource with an empty body?
That's a little hard, since what if you intended for it to be a collection?
Do we just disallow putting a null resource under version control (for a
similar reason that I advocate not supporting null locks :-)
Target might want to be Target Revision to make it more specific. What else can
ge Target-Selector be? Might not be needed here in the definition, but that's
where the question came up for me.
The target could be a working resource.
Baseline: (look for . . in a number of places in the document) 1st paragraph,
last sentence: ..."a baseline contains a revision of the versioned collection
and a revision or baseline".... Which is it, a revision of a member, or a
baseline? A revision of a non-collection and a baseline of a collection? What's
the difference between a revision and a baseline or a collection in this
context? (answer: the baseline is just a deep revision). Maybe no change
required, I'm just thinking.
I think it's OK the way it is.
I'll be looking for where repository is used. If it never appears in the client
space, then the protocol shouldn't need the concept. It should be an
implementation concept only. Note I continue to believe the protocol should not
be specifying where activites and configurations go. Versioned resources yes,
because they are owned by the server, the client uses a mapped URL to get to
them. But the protocol should only know about this URL, not the physical
location of the versioned resource. But I'm still open.
Added to the issues list ... something for washington ...
2.1 The initial revision MAY become the target depending on the workspace
current label, current activity, or RSR.
Done (just deleted that sentence).
2.2 WebDAV level 2 should be class 2.
Done.
Does a server have to support immutable
revisions? Last paragraph says mutable revision support is optional, but doesn't
say anything about immutable revisions.
A server doesn't do anything special to support immutable revisions, other than
failing an attempt to use DAV:overwrite as a DAV:checkin-option. So basically
supporting mutable revisions is supporting the DAV:overwrite option.
2.4 sets of related resource -> resources
Done.
2.5 User "revision selector" instead of "rule element".
Done.
2.7 The logic isn't consistent. Say you have a working collection of a versioned
collection. Now you want to add a new resource to that collection. You use PUT
to create the new resource, but since its not versioned, the PUT fails. So the
only way to add a new resource is to CHECKIN a null resource. But this seems
more like an error than the PUT. You're checking in a resource that you never
checked out, and doesn't exist.
I changed the spec so that it automatically puts the resource under version
control in this case.
I have less problem if the members have to be
checked in before the collection can be checked in.
That we can't require. It's perfectly reasonable to be done adding or
deleting members of a collection, while still be working on resources
in that collection.
2.8 makes a reasonable case for repositories, but it seems like the protocol is
getting pretty deep into implementations here. Some servers might not have
repositories at all, there won't be any of these restrictions. Others (like
DAV4J) may have very different semantcs for partitions of the namespace because
the server has multiple underlying repository managers with restrictions on
relationships between the resources in them. OPTIONS on a resource should
provide the necessary information. Users might not be aware of these boundaries
inside the server until an error occurs (mostly through bindings across
repository managers). But this will be true for many non-versioning methods too.
On the issues list.
Section 2 is missing the locking semantics that were in the versioning model
introduction. We should include it here and address the issues it raises.
Maybe you can draft something for this. The only thing I want to say is that
a LOCK maps to a CHECKOUT and an UNLOCK maps to a CHECKIN in the default
workspace.
3.2.1 Boolean in other WebDAV headers (DAV:overwrite) is T and F. Versioning
should be consistent.
Done.
3.2.2 should be a reference not copy.
Done.
3.3.1, what are the empty parens for? (mutability, etc.?)
Yes, but I don't like the empty ones ... they're gone now.
3.4.3 (and others), last sentence: what XML document? Do you mean the value of
the DAV:default-workspace element in an entity body?
Got rid of this sentence. This is related to the property resource issue,
which is on the issue list.
3.4.7 PUTPROP->PROPPATCH
done.
3.5.4 Seems more natural for this to be labels, not labeled. Labeled looks more
boolean, and labels is consistent with the property on a versioned resource that
plays the same role.
done.
3.5.6 What is DAV:workspaces used for? Just for reporting?
This is the property that tells you if this revision is checked out,
and if so, into which workspaces.
3.5.9 merge-precdecessors: the client should be restricted to merge only
revisions of the same versioned resource, and only if they are on different
lines of descent. Otherwise merge relationships are not meaningful. This and
merge-successors are good examples of how property collections don't work well.
There are a lot of semantics associated with merging and integrity relationships
that must be maintained. Doing this by allowing clients to directly edit
collections is inappropriate. Instead there should be a MERGE method that
maintains the semantics. It's ok to have the properties for reporting purposes,
but no for establishing the relationships.
Placed on the issue list.
3.5.10 indicates merge-successors is readonly, but describes how to add and
delete new merge successors.
Done (removed the readonly mark).
3.6.1: The revision selector for a baseline would have to include the URL of the
associated collection, and the baseline id. A baseline is the only revision
selector that has a compound name. This will complicate the revision selection
rules.
No need for a collection/id pair. Just use the URL to that baseline.
A baseline doesn't have labels? The duplication between baseline, revision, and
configuration looks suspicious. Maybe we need some factoring.
Note that baselines share most of the properties with revisions, so that
would be the likely candidate (thus the alternative name, "deep revision").
3.7.1 Wouldn't the request have to know the workspace in order to get the
workspace property of a working resource?
Done (got rid of that property).
3.7.3: doesn't every baseline have to have a corresponding revision of the
versioned collection?
I'm not sure what you mean by "corresponding". Every baseline has to select
a revision of its versioned collection, but several baselines of a versioned
collection can select the same revision of that versioned collection.
I think the XML element definition fo checkin-policy is wrong. It implies each
item can be specified more than once, but this doesn't make sence. And there's
no extensibility built in, say PCDATA.
Some can be combined, e.g. DAV:overwrite and DAV:keep-checked-out
3.7.4 Need more control over merge. To ensure semantics, should use a MERGE
method instead of directly editing properties which are likely live and not the
implementation of persistence for the merge successor/predecessors.
Added constraint that only appropriate revisions can be added to the
collection. How is constraining a "property collection" any harder than
constraining a method. You write down the constraint, and servers and
clients must follow it.
3.8.2: rsr-baseline: must have the URL for the collection and the id of the
baseline. A baseline is like a revision and must be addressed by its id.
See above. A baseline has a URL, and can be addressed by that.
General question on the introduction of conflicts in the RSR: many of the
revision selectors indicate they don't ever create conflicts, or only create
conflicts in certain circumstances. Aren't conflicts created not by a particular
revision selector, but by the presence of more than one revision selector in the
RSR, each of which might pick a revision that is not on the same line of
descent?
Yes, but only for the DAV:rsr-merge operator (or for DAV:needed-activities).
The DAV:rsr-or operator just does "first match".
rsr-configuration: this one is a problem as the RSR must be used to select the
revision of the configuration that the RSR uses to see if the configuration
contains a revision of the target resource. Since configurations can't contain
configurations, this isn't a problem, but it may have undesirable implementation
consequences. The configuration used by the RSR can change without anything
changing in the RSR itself. Say the configuration selected is one labeled Foo,
and Foo moves to a different configuration. Perhaps we need to restrict a
revision selector to a revision of a configuration, just like baselines.
Whenever a specific revision is required, the workspace isn't used, and a
specific id is required. Can't use a label because that could move.
Added constraint that a versioned-configuration cannot be used, but a
configuration revision can be.
3.8.3 and 3.8.4 should be current-label and current-acctivity to highlight their
role.
done.
3.9.3 Why can't an activity be used in more than one workspace at a time?
Workspaces keep working resource separate, so why can't more than one user be
working on the the same activity at the same time. This is common in branching
systems where branches represent some larger unit of work.
done (removed restriction).
3.10 I'd like to see if there's a way this section could be removed. It sounds
like implementation detail. I realize its just using the protocol to describe
some behavior, but I think this is overly restrictive and nothing the client
needs to know. For example, activities, workspaces, and configurations are
resources created by users for user purposes. The fact that the server uses them
too is not important to users. Users will want to put their activities in their
own collections, not be forced to put them in some server-specific location,
perhaps mixed up with a lot of other unrelated activities.
Ahh, the good ol' repository question (:-) ... it's in the issues list.
Section 4, 1st paragraph: methods inherit all of the WebDAV functionality should
be methods have all of... We should avoid inherit as it as other uses and
carries lots of expectation.
done.
4.1 GET on resources with no body returns an empty body with no MIME type.
done.
4.2 last paragraph: seems like PUT to null resource in a working collection is
how one would begin to add a new member to a versioned collection.
done.
4.5 Seems like it should be OK to copy:
workspace: it would be a new workspace with the same RSR, but none of the
working resources
activity: it would just create a new activity with some of the properties copied
configuration: should work fine
I think it would be misleading and not that useful to support a copy
that cannot copy the key properties of the resource.
4.9 checks out the target, not the versioned resource.
done
This doesn't seem
consistent with lock. Lock is a dynamic access control mechanism. Locking a
versioned resource should be the same as setting the single-checkout property.
checking it out in the default workspace has the right semantics for down level
clients working against auto-versioned resources ... the PUT that would auto-
version fails because the resource is already checked out into the default
workspace.
Only the lock owner can do the checkout. Lock on a revision does the same thing
for the revision. Lock on a workspace prevents any checkouts in that workspace
(because only the lock owner can update the properties), etc. These are the
semantics from the model introduction I think.
I think these metadata items want ACL's, not lock tokens. But I've added
it to the issues list in any case.
4.11 OPTIONS is on the resource too, not just the server. I hope the client
doesn't need to know repositories on the server.
I think this is the repository question again? (:-)
5.1 I don't know what a standard data container is. I think its a resource
without a resourcetype property.
JimW: What did you have in mind here ... is "standard data container"
a standard term?
Seems too bad that MKRESOURCE can't initialize the whole state of a resource in
a single atomic operation. We don't need it, but user's might. This could be
done if we used multi-part entity request bodies.
I've heard experienced folks say you "can't do that". I never pressed them
on it, but they sounded pretty confident (:-).
5.5 Why can't a REPORT be on a resource? It would just return if that one
resource changed, added (compare-request doesn't exist), or was deleted (request
resource doesn't exist). Isn't this the base case for the recursion implied in
the other resources.
Yes ... didn't get this done, so just added it as a "to-do" item.
5.4.6 looks like the conflicts-response should have been
conflicts-report-response in the example. Or its wrong in 5.4.2.
done.
6.1, so unlike all other methods, CHECKOUT doesn't use the default workspace.
Irregularity creeps in... Pehaps the client should be required to do MKRESOURCE
first to create the workspace (or checkout token), and then provide it on the
CHECKOUT. This is not a significant overhead, and the client is very likely to
use this same workspace for other CHECKOUTs. I don't like servers implicitly
creating workspaces. This does not imply that the workspace has to have a
revision selection rule, or that the server has to support extended workspaces.
I'll defer this to Chris ... he's the one that advocates checkout tokens
(which is what this provides).
2nd to last sentence should be "A subsequent request on the same URL that
specifies that workspace in a Target-Selector header will be applied to that
working resource."
done.
6.1 4th precondition, DAV:activity and/or DAV:label (or current-activity,
current-label) must be set. Its OK to use both.
done.
Missing precondition, if DAV:activity is specified, the resource cannot be
already checked out in that activity.
done.
The preconditions should be specified more logically too. For example, If the
DAV:single-checkout property of the selected versioned resource is set, the
resource must not be already checked out in any other workspace.
I'd be concerned that that would turns something very concrete that
you can verify into a vaguer statement that might be misunderstood.
We should discuss this. I could be argued into it.
Last
precondition: a revision cannot be checked out twice in the same workspace.
That is implied by the fact that you can't apply CHECKOUT to a working
resource.
Marshalling, how is the Target-Selector overridden with a specific label or id?
It isn't. The Target-Selector with a label or id is just for folks with
lightweight workspaces that don't have rsr's. For folks with workspaces,
overriding with a specific label is far less common, and can be done by
accessing the DAV:revisions or DAV:revision-labels collections.
We need the Target-Selector to specify the workspace for collections in the URL
path, while overriding the Target-Selector for the leaf element of the path.
We could do that, but I argue we don't "need" to do it.
Why is there a propertyupdate element on a CHECKOUT? Shouldn't the be a
PROPPATCH after the checkout? If this is for checkout policies, then perhaps we
should simplify CHECKOUT, and let clients do CHECKOUT, PROPPATCH, and UNCHECKOUT
if the PROPPATCH (or anything else they want) fails as they wish. I don't see
why we need this in the CHECKOUT protocol. There doesn't seem to be any reason
this needs to be atomic, and there certainly shouldn't be any performance issues
as CHECKOUTS are not done that often.
done. I'm not sure who wanted this (maybe Brad?), but I'm certainly happy
to go with the CHECKOUT PROPPATCH approach.
I'm especially against this if there are a
whole lot of restrictions on what can be in the propertyupdate to restrict the
updates to things having to do with checkout and a subsequent checkin.
No need for any restrictions.
I don't like how specific the postconditions are. The should say:
The revision is checked out in the selected workspace in the current activity if
any. All the rest sounds like implementation detail and tends to hide the
meaning of the method. Perhaps we need to include both the logical and physical
pre and post conditions.
It's certainly not implementation detail ... it's the semantics of the
operation defined precisely. I believe this is the same issue raised
earlier? If so, it's on the issues list.
Result: the checkout response must be in a multistatus, not just a response
element.
To handle the property update?
6.2 The sentence "If the server supports mutable revisions." appears out of
context.
fixed.
I don't think we should overload checkin with uncheckout semantics.
This was a "trial balloon". In many ways, uncheckout is just a variant
of "I'm done with this", especially when you consider the
" CHECKIN identical-uncheckout" option.
Again, CHECKIN is doing PROPPATCH work. This is not a propertyupdate, its a set
of parameters for the CHECKIN method. We should not reuse the propertyupdate,
but rather create a new element, specific to the method. Otherwise we have to
specify a whole bunch of restrictions about what can go in the propertyupdate.
I don't think we need to put on any restrictions. This seems like a pretty
natural place to allow you to specify CHECKIN options, but I could go either
way.
DAV:uncheckout is a control couple. This is not good style. Use a separate
method. There's no reason to conserve them. Control couples appear to make the
protocol smaller, but they really add complexity.
Not if they are logically very similar in basic intent (i.e. "I'm done
with this resource"). We already have DAV:overwrite which doesn't create
a new revision, and DAV:identical-uncheckout which only creates a new
revision if it has changed, so DAV:uncheckout seems to fit in very smoothly.
Notice that most of these
checkin policies could be marshalled in simple headers.
So we could use up the single header namespace, instead of using XML
which has user-defined namespaces ? (:-)
7. The paragraph about Target-Selector specfies a revision id or label is
incorrect. The selector "self" cannot be applied to collections on the path
because its a revision of the collection that's needed, not the versioned
collection as a whole.
And if so, it will "correctly" return an error (you should be using a workspace
to look at things in versioned collections).
The revision says what the members of that revision of
the collection are which can be used to validate the next entry in the path. So
we need two headers, the Target-Selector containing the workspace, and a
Revision-Selector that overrides it for the leaf resource. Its the
Revision-Selector that can have "self" not the Target-Selector.
Added to the issues list.
Issues:
1. Do members of a verioned collection have to be versioned resources?
Added.
2. Should the server specify where activities, workspaces, and/or configurations
are located in the URL namespace?
Added.
3. Are revision ids and revision labels in the same namespace (i.e., specified
in the same header and XML elements)?
Added.
4. What does it mean to LOCK a workspace, activity, configuration, baseline,
versioned resource, revision?
Added.
5. Property resources aren't really resources or collections. You can do a PUT
or MKCOL in them, GET, etc. We're trying to reuse some of the WebDAV methods to
specify the protocol for new method semantics. We don't want two ways of
specifying these semantics, XML and property resources. Perhaps neither is
correct and we should be using additonal methods.
Added.
6. Can an RSR contain a revision selector that is a versioned resource (e.g., a
configuration)? No. Have to specify a particular revision using the revision id
(labels can move).
I agree. Just updated spec, so not added to issues list.
7. Can a revision selector have a compound name?
I believe there is no need (yet), so I'd defer adding this to the issue list
until we identify the need for it (it is of course easy to allow this).
8. LOCK in a versioning server needs to be better defined.
Versioned resource
revision
working resource
configuration
activity
workspace
baseline
This is issue 4 above, I believe.
And again, great review!
Cheers,
Geoff