Next message: by way of : "More recent version of the draft?"
Date: Fri, 7 Jan 2000 00:51:57 -0500
Message-Id: <10001070551.AA19376@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Comments on versioning protocol
From: "Vasta, John" <jvasta@rational.com>
1.1 "LOCK/UNLOCK requests can be mapped into CHECKOUT/CHECKIN requests" is
no longer true, right?
Correct. I'll delete this statement.
2.1 Unversioned resources can also be created by MKCOL, COPY, and MOVE.
Versioned resources can also be created by MKCOL and COPY.
Rather than enumerate all the ways to create resources, I changed this
to "e.g. by PUT".
Does CHECKOUT really turn a versionable resource into a versioned
resource? If so, it cannot create an initial revision which is a copy of
the versionable resource, since it is still checked out (there won't be a
revision until it is checked in).
Fixed this to say that an empty initial revision is created, and that
the versionable resource is copied into a new working resource.
We had a thread not too long ago about whether we should create a
null initial revision, or let you have an initial working resource
that is not associated with any revision. I'll go with the "null
initial revision" for now, but this is probably still an open issue.
2.7 How can a repository contain workspaces? Can a workspace contain
resources from more than one repository?
That's a good point ... workspaces and repositories should be orthogonal.
I'll just delete the "workspaces" property from the repository resource.
3.4.4 If DAV:auto-version takes the same values as DAV:checkin-policy,
then it does not seem possible to enable auto-version without having a
non-default checkin-policy, since the only choices are "uncheckout",
"overwrite", and "keep-checked-out".
Good point. I've added a DAV:new-version value, which is the default.
3.7.2 If an rsr references another workspace, is it expected to always
track the rsr of that workspace, or only copy it at the time the rsr is
set?
Another good point. In the spirit of "RSR simplification", I'll remove
the statement that a workspace can be an RSR element.
4.3 Aren't "resource properties" gone now?
Yes. I'll move this functionality to a "Property REPORT" which lets
you get the properties of all the resources identified by property
href's (in a single REPORT).
4.7 When the destination collection of BIND is a versioned collection, the
new binding cannot be added to the target of the versioned collection; it
must be added to a new revision of the versioned collection.
Unless the target of the versioned collection is a working collection.
Therefore,
the destination must either be a working collection, or auto-versioning
must be applicable.
Yes. I'll cheat a bit by saying "BIND acts like a PUT on the Destination"
(since PUT goes into gory detail about all this).
(Should auto-versioning be allowed? Won't only
versioning clients issue BIND requests?)
BIND's can be issued by non-versioning clients that support the BIND
extension.
4.8 Same comments from BIND destination apply to MOVE. (Also, fix
copy/paste error: BIND should be MOVE.)
Done.
4.X Still need to mention MKCOL.
Done.
5.1 Shouldn't a precondition of MKRESOURCE for versioned-resources be that
the parent collection is checked out?
I'm tempted at the moment to just say that CHECKOUT is *always* used to
created versioned resources (and not MKRESOURCE). Does anyone object?
5.6.2 I think the DTD for compare-report should be
<!ELEMENT compare-report (added|deleted|changed)*>
so that the child elements can appear in any order. (When used to
represent the comparison of text files, it will be important to have them
in "file order".)
Done.
6.1
Why must workspaces have DAV:current-activity or DAV:current-label set?
Seems like some simple clients will not want to worry about either
activities or labels.
Good point (I think Jim Amsden made this point as well). I'll delete this
prerequisite.
If anyone objects to any of these changes, please let me know (I can always
back them out).
Cheers,
Geoff