Next message: Geoffrey M. Clemm: "Re: Comments on deltav-versioning-03.1"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525689C.00101D9C.00@d54mta03.raleigh.ibm.com>
Date: Tue, 7 Mar 2000 21:50:01 -0500
Subject: Versioning Spec-03 Review - core versioning
Just a nit, I like examples to look real if possible. Definition of
predecessor/successor example could look more real and might be easier to
understand.
2.1 never really says how a versioned resource is created. Should mention
the VERSION method.
2.2 Can the client specify the workspace in core versioning if they want to
reuse one? Or are they always returned by the server and the client has to
group them into a logical workspace?
2.3, end of the second paragraph: The same revision label can be applied to
a revision of any other versioned resource.
3.1.5 stable-href syntax isn't really a different syntax, but rather a
property of the use of an href in a context.
3.2.1 indicate each revision can have a differen author.
3.3 shorten DAV:versioned-resource-resourcetype to just
DAV:versioned-resource. Its more consistent with DAV:collection, is
shorter, and less redundant (i.e.,
<DAV:resourcetype>DAV:versioned-resource-resourcetype</DAV:resourcetype>
has one too many resourcetypes's.
3.3.1 are the DAV:revisions ordered in any way?
3.3.3 DAV:default-revision isn't consistent with the default workspace
concept. It introduces another revision selection mechanism. Need to
resolve this in the context of the default workspace.
3.3.4 Saying auto-version is like CHECKOUT/PUT/CHECKIN is like saying MOVE
is COPY/DELETE. We may regret saying this later, and the operation needs to
be atomic.
3.4.2 I get nervous about DAV:revision. First, its not clear who will use
this or how easy it will be to use. If clients are doing all the mappings
of human URLs to DAV:revision URLs, then this is OK, but seems like this is
usually the server's role. Second, once a server gives out this
information, it will be required to maintain it. That is, the server won't
be able to reorganize its contents in a way that might invalidate any of
these generated URLs. This might reduce server implementation flexibility.
3.4.5 Are revision labels, like revision ids, required to be valid URL
segments?
3.4.7 Indicate this property will be empty if there is not checked out
working resource.
4. seemed to have lost some of the details on how versioning effects other
methods. I think MOVE, COPY, and DELETE need some attentation as well as
LOCK/UNLOCK. Maybe a revision or versioned resource can't be moved? Copying
a versioned resource copies only the selected revision to a new unversioned
resource? All the proposed semantics for locking a versioned resource,
resource, workspace, activity, and configuration?
5.1, 207, needs to be consistent with result of PROPPATCH.
5.2 Status codes reference MKRESOURCE instead of REPORT. Looks like there
could be many more status codes. Are any dependent on the report type?
5.2.1 could these names be shortened from *-report-request to just
*-report. Isn't the request implied by the context in which the element
appears? Example 5.3, D:available-report in a d:report-request is what I
mean. Note the example doesn't match this section in any case.
5.3.3 (and others) URI shouldn't contain the protocol and domain name.
5.4 Property report should be DASL. Too much work has be done on DASL for
us to just ignore it.
6.1 Didn't see anything that specified what was a versionable resource.
Could this vary from server to server? Are there just some resourcetypes
that would never be versionable? Should these be the ones we list?
Postconditions 2) copy of the versionable resource contents and properties
(should be ok as written though).
3) What is the DAV:resource-id?
6.2 request marshalling 2) what about the workspace header? Can the client
specify a workspace to reuse?
Status codes 405: if the workspace can't be specified, then it can't be
invalid.
What about status codes for already checked out? What about violations of
the checkin policy?
6.2.1 Content-Type not valid if there is no entity request body.
6.3 request marshalling 2) workspace that identifies not contains the
selected working resource.
Status codes: should 405 be 409 Conflict?
6.4 Remove reference to DAV:activity.
6.4 request marshalling 2) workspace that identifies not contains the
selected working resource.
Postconditions 1) I don't like a CHECKIN doing a PROPPATCH.
2) Couldn't find a definition of DAV:resourceid
5) move stuff associated with activities to advanced.
6) do you mean current label instead of selected label?
6.4.1 D:identical-abort not defined in 3.5.3. Response body not defined.
6.5 LABEL only adds and removes labels, doesn't change labels.
Should LABEL take a depth header to apply the label to all the members?
Request body not defined.
6.5.1 D:request not defined. element D:request terminated with D:response.
7.1 Reference to revision selection rule should move to advanced section.
Default workspace is not defined.
What is a Vary header?
Last paragraph, why not just return the Revision-Selector header?