Review of dav-versioning-01.3
jamsden@us.ibm.com
Tue, 1 Jun 1999 14:17:49 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256783.006A5879.00@d54mta03.raleigh.ibm.com>
Date: Tue, 1 Jun 1999 14:17:49 -0400
Subject: Review of dav-versioning-01.3
Section 1 Introduction: automatic versioning support for HTTP/1.1 and WebDAV
class 1 and 2 clients
3rd item: its not files or branching, it's just basic parallel development.
4th item: configuration's aren't for parallel development. Should have said
configurations and sophisticated parallel development.
Section 1.1: should specify relationship to DAV class 1 and 2 servers too.
Section 2 Concepts and Definitions: Terms and definitions should be taken from
the goals document. Those given here are not as complete as the ones in the
goals document, and we want to avoid redundancy, update anomolies, and
inconsistencies. Introduction should be taken from the overview in the
versioning document.
use resources like index.html instead of foo.htm to make the examples more
realistic and avoid windows 8.3 file restrictions.
Section 2.2: the revision the method is applied to should be called the
"selected revision", not target. Target is too overloaded.
2.4 The definition of revision name is missing.
2.5 Its just revision label in the goals document, it isn't necessary to
introduce label-id as an alias.
2.6 Mutable property means something different than mutable revision. Any
property of a mutable revision can be updated without creating a new revision
with checkin overwrite, just like the contents. A mutable property is one that
can be changed without checking out the revision at all. reviion->revision.
2.7 Comments similar to mutable object/property. Last sentence: created not
create.
2.8 Working Resource: ...can be directly modified by a PUT or PROPPATCH request,
or any request that changes the persistent state of the resource contents or
properties.
The pictures seemed to get moved around when the document was printed, and they
crossed page boundaries. They should follow the definitions?
2.12 Workspace should include both a current label and current activity. They
can be used together and this would allow a more seamless transition from level
1 to leve 2 versioning with activities. The current label can remain set and
some checkouts can be done with activities and some without.
Need to have consistent use of '-' in definitions and header names. Sometimes
they are used in definitions and other times not. What's the convention? DAV
class 2 didn't use '-' to separate words in property names. Perhaps it should
have, but should we be consistent with the versioning headers?
2.13 Default Workspace: The default workspace must have "latest" in its revision
selection rule (unless administrator changes it to something else). If so, then
the DAV:current-label property doesn't need to be set. Not clear what it should
be anyway, and if it is set, then this label would need to be in the RSR. Simple
workspaces don't support RSRs.
2.17 Baselined-Collection: its not really a special type of versioned
collection, all versioned collections can have baselines.
3.3 Discovery: can we use the DAV header and introduce class 3 and 4 instead of
introducing a new header and leveling scheme? Can we use OPTIONS * to get
properties on the server as opposed to a resource?
4.1.2 Immutable/Mutable Properties: how does this relate to live/dead
properties. Note that some of the versioning properties should not be copied at
all, and should definately not be copied live to the destination. This property
meta-data could be specified as attributes of the property. Yaron, is this OK?
4.2.4 DAV:workspaces: why does a revision have to know workspaces? To know where
it is checked out?
4.2 Revision Properties: missing a reference to the associated versioned
resource this resource is a revision of?
4.2.5 Locking a revision was supposed to do what DAV:single-checkout does. Do we
need both? Single-checkout is a property of the resource while locking a
revision is access control. So we probably do need both.
4.2.11 DAV:vresource-id: use URL of the resource this is a revision of instead?
This would allow down-level clients to access the resource without knowing about
ids. Indicate it is assigned by the server and cannot be changed or used as any
revision label. Same for section 4.3.6.
4.4.1 DAV:current, use DAV:current-label and add DAV:current-activity (for level
2 versioning).
4.4.2 DAV:revision-selection-rule: Use "revision selector" instead of "elements"
to be more specific. Last paragraph: what other revision selectors might be
possible? Will this introduce interoperability issues? How would the support be
discovered? The servers can support whatever they want, but the interoperability
problem comes from the client being able to specify server specific revision
selectors. If its just an extensible XML document, this isn't too bad, but
clients won't want to expose the XML directly.
5.1.1 GET (and most of the other methods), missing preconditions, semantics,
postconditions, detected errors. Also revision selection semantics aren't
described anywhere.
5.1.3 PUT: ..."When PUT is applied to a null resource that is an internal member
of a working resource for a versioned collection...". Should we stop using the
term "internal member" and just use member since there is no distincation
anymore between internal and external members?
5.1.4 PROPPATCH: should use DAV:auto-version just like PUT. This would only
apply to immutable properties as mutable properties can be modified without
checking out the revision.
5.1.5 DELETE: there is nothing to delete after an UNCHECKOUT as it deletes the
working resource itself.
5.1.6 COPY: The revision copied should be the specified revision or the revision
selected by the workspace. "tip revision" is not defined. If no version-selector
is specified, the default workspace is used. Is there a way to copy or move the
whole versioned resource? To another server?
5.1.7 MOVE: Why can't a specific revision be moved? What else could be moved for
a versioned resource? Even latest is a specific revision. MOVE is best effort
which means the source wouldn't have to get deleted, but the binding in its
parent collection might be removed if it is unversioned, or checked out.
5.1.8 LOCK: Locks are access control, not authorization. The owner of the lock
should be able to perform the operation, but not others if its an exclusive
lock. See the section on locking in the Versioning overview: Lock a versioned
resource - only the lock owners can checkout any revision in any activity of
that versioned resource. Lock a revision - only the lock owners can check out
that revision in any activity. Lock an activity - only the lock owners can
checkout a revision in that activity. Lock a workspace - only the lock owner can
checkout revisions in that workspace or modify the workspace current label,
current activity, or revision selection rule.
5.2.1 MKRESOURCE: what is this method for? Creating resources with a specific
resource type that cannot be changed? How about allowing resource type to be
changed only if it is not set? Or let it be changed to anything and the user
gets what he asks for? (Doesn't work for resource types WebDAV needs for its own
purposes though). How is it different than PROPPATCH or DELETE followed by
PROPPATCH? What does it have to do with versioning? If PROPPATCH doesn't create
a resource that doesn't exist, should we just add a header to this method rather
than create a new method?
5.2.2 CHECKOUT: Use lock on a revision instead of DAV:single-checkout. Doesn't
say it fails if its already checked out. Seems strange to have simple versioning
systems implicitly create anonymous branches with no merge support without even
issuing a warning.
Does CHECKOUT fail of any if the policies specified in the DAV:checkin-policy
cannot be satisfied? DAV:checkin-policy might be a good candidate for
simplification.
5.2.3 CHECKIN: doesn't describe checkin mutable to create a mutable revision.
Doesn't say anything about checkin immutable when the predecessor is mutable.
Doesn't describe checkin with overwrite.
Checkpoint revision isn't defined. There's no header to specify create a
checkpoint. This overloads checkin to do something that isn't a checkin, that
is, something that releases the revision so other users can check it out.
Consider using a separate method for this function.
5.3.1 Version-Selector: can any revision selector be used? Label, activity,
configuration, or workspace? If so what's the precedence order if the names
collide. A label could be the same as a workspace name.
6.1.1 Is this the same as 4.2.4? Says what the representation is, but doesn't
say what its for. The workspaces this revision is checked out in? Isn't this a
revision property, not resource?
6.2.1 Dav:history-resource-id: isn't this needed for version-management too?
Should it be a URL instead of an id to make it more useful to down-level
clients?
6.2.2 DAV:merge-predecdessors: this one contains bindings while other similar
properties contain ids. What does it mean to register a merge, do the updates,
and then delete the merge predecessor? Isn't some history lost? After thinking
about it, this doesn't seem like a problem after all. The history of the change
is still captured in the new revision, and deleting the merge predecessor worst
case will only cause the merge conflict to re-appear.
6.4.1 Need both DAV:current-label and DAV:current-activity.
6.5.3 This means that two people can't work on different resources in the same
activity in using different workspaces. Why is this restriction required? It
seems to significantly limit the value of activities.
6.6.1 DAV:roots: are these cust comments indicating what URL segments were bound
to the revisions when the configuration was created, or is something done with
them?
6.7.1: DAV:baselines: why is this plural? Doesn't the versioned collection only
have one baseline which is a versioned configuration. Its the configuration that
has multiple revisions, not the collection that has multiple baselines? ... is a
configuration revision whose DAV:roots contains a revision of this collection as
its only member. DAV:scope no longer applies.
6.8.1 DAV:versioned-collection: isn't this information in the DAV:roots
property?
6.9.3 remove the last sentence about escaping reserved characters.
6.10.1 DAV:history-resources: This seems to be implying a specific server
organization. Didn't we say this would be a distinguished collection maintained
by the server, say /repo/histories, /repo/activities, etc.? Is this a server
property, not repository?
7.1.8 CHECKIN: Separate out baseline creation so that a baseline can be created
without having the collection checked out?
7.2.1 GET-CONFLICTS -> CONFLICTS
7. Need DTDs for all these elements.