Next message: Geoffrey M. Clemm: "Re: Review of core versioning spec 05"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525691A.000AF8D2.00@d54mta02.raleigh.ibm.com>
Date: Tue, 11 Jul 2000 21:59:45 -0400
Subject: Review of core versioning spec 05
Abstract: should this mention configurations or baselines. This is an
important concept to include.
mutable revisions are not in core versioning?
default target is defined, but not target.
2.2: a versioned resource does not display content & properties of a
revision. It also doesn't seem like the point of SET-TARGET is to modify
the state of the verisoned resource. Perhaps this section should read: "The
SET-TARGET method may be used to set the revision to be used as the
default-target of a versioned resource. The default-target revision is that
revision that will be selected when the request URL refers to the versioned
resource, and no Target-Selector header is present."
2.3 last sentence of 1st paragraph: ... can be given to two revisions
from...: remove two, it can be given to any number of revisions.
3.2.1 creator-displayname has limited value: can be changed anytime by
anyone, syntax isn't specified, doesn't correspond to a principal. Why not
use the principal? Don't we think authentication should be required to
check something in?
3.3.1 The default revision could be indicated by:
- an isDefault boolean property on a revision
- a "default" label functor on a revision
- a label on the versioned resource (let the server figure out what
revision has the label)
This would eliminate one use of server generated URLs.
3.5.1 DAV:checked-out needs to be DAV:predecessor-set for working resources
to be consistent with support for advanced versioning merging. Why not use
the same property for the same function in working resources and revisions?
5. a versioned resource isn't checked out, the target revision is.
5.2.1 Add versioning methods to OPTIONS Allow: response.
5.6 Do we need to define meta-data on properties that allows them to be
protected and able to be changed without creating a new revision? Users
might want to be able to define their own properties with this kind of
behavior.
5.10 Then what are the semantics of LOCK on a revision, versioned resource,
etc.?
6.1 Do we want to return a 20x status code if VERSION is applied to an
already versioned resource just to indicate to the client that this was the
case?
6.2 A CHECKOUT request is applied to a revision, not a versioned resource.
If the request URL is the versioned resource, then the target revision is
selected (either the default-target, or the target selected by the
Target-Selector header).
Why is there a checkout element in the entity request body to specify
something that can be easily specified in the request URI or the
target-selector? What if the CHECKOUT request URI is a revision URL and the
checkout revision in the entity request body is a different revision? This
seems redundant.
DAV:checked-out should be DAV:predecessor-set.
6.3 405 The request-URL did not identify a working resource
What does it mean to checkin with a Target-Selector header? Does the
Target-Selector header have to be the working resource URL?
6.5 Seems like the Target-Selector header should be able to be used to
specify the target in SET-TARGET instead of an entity request body. This
would help unify target selection.
6.6 Are labels already available in an existing report? Having LABEL do
editing and reporting complicates the method with unrelated functionality,
and confuses the entity response.
7.1 How can the DAV:successor-report be applied to a versioned resource?
Versioned resources don't have successors and predecessors.
The report returns server generated revision URLs. These will likely not be
very meaningful to the client who would prefer the versioned resource URL
and a label. How will a client be able to display this more meaningful
information in a printed report?
7.2 Again, how can the DAV:checkout-report be applied to a versioned
resource? Do you mean using a versioned resource URL and Target-Selector
and the method applies to the default-target if the Target-Selector isn't
specified?
7.3 do we want to introduce a "latest" functor for the Target-Selector
instead of using a DAV:latest-checkin-report? Then users can operate on the
latest revision in a single method.
7.4 How would the client be able to predict what information will come back
from the DAV:revision-tree-report if the server can arbitrarily decide
which elements to eliminate?