FWD: Questions on the 02 versioning protocol draft
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 13 Aug 1999 14:34:40 -0400
Date: Fri, 13 Aug 1999 14:34:40 -0400
Message-Id: <9908131834.AA26062@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
Subject: FWD: Questions on the 02 versioning protocol draft
From: jamsden@us.ibm.com
Jeff,
Good set of questions. Comments in <jra> tags below...
Jim Whitehead, see the comments on MKRESOURCE and PROPPATCH below.
Jeff_McAffer@oti.com (Jeff McAffer OTT) on 08/11/99 02:29:13 PM
I writing up the REPORT method and making an example for MKRESOURCE I
came up with a fair number of questions...
1) are compare and conflict reports deep? That is, if the specified
resource is a versioned collection, does the report include all
transitively reachable resources?
<jra>
The conflict report applies to resources (and collections) visible in the
current workspace. So this indirectly implies the reports are deep, but that is
not really the point.
</jra>
2) If #1 = yes, when we hit a non-versioned resource during the
traversal, what happens? I suggest that the report not report on
non-versioned resources.
<jra>
There can't be conflicts with unversioned resources because they only have one
revision, and therefore it is impossible to have conflicting revisions. This
isn't really a special case, but a base case.
</jra>
2.5) If #1 = no, why? How would I, for example, find ALL conflicts.
3) Observation: if conflict reports are transitive then when we hit a
versioned collection which is ambiguous (i.e., a conflict) the report
cannot continue the traversal of its the collection's children as it is
ambiguous which set of children should be followed.
<jra>
The report can continue by using the first selection from the workspace to
derive additional conflicts. This may create conflicts that are uninteresting,
and will require the user to get the report a number of times while resolving
conflicts because some of them may go away as the result of incremental
resolutions. I think this is expected though and impossible to avoid.
</jra>
4) sections 5.2.2.2/5 talk about having activities in configurations.
This is confusing. What does it mean to have an activity in a
configuration?
<jra>
An activity in a configuration says select the latest version in that activity,
just like it does in a workspace. A configuration could be viewed as a
persistent workspace, or a convenience for capturing, recovering, and/or reusing
revision selection rules (perhaps more than one, one for each configuration) in
a workspace. In this case, the revision selector is floating, so the
configuration won't select the same revision all the time. That's not what
configurations are generally used for, but I don't see any reason whay we should
rule it out.
</jra>
5) how does one create a configuration? MKRESOURCE is the likely
candidate but it is expecting a Request-URI. What is this supposed to
be? Is it possible to have MKRESOURCE return a URL in its response body?
This would allow servers to put configurations wherever it wanted them
and tell users where they were. Alternatively, the only way to make a
config is to deep check-in a collection and then access its baselines
property. This seems circuitous and reduces the usefulness of
MKRESOURCE. Note that I am looking at configurations as "metadata" which
should generally not appear in the normal user URL space.
<jra>
Users create resources where they want them. Configurations are user resources,
so they should specify the URLs. If the server needs to have all the
configurations in one location for its purposes, then it should use links to
hide this implementation detail. So I don't think of a configuration of metadata
that doesn't belong in the user URL space. They are user resources, not server
resources.
We talked about having PROPPATCH be able to create resources and eliminating
MKRESOURCE. This should be discussed on the mailing list. Jim, as the owner of
this method, can you take care of this?
</jra>
6) How does one add something to a configuration? That is, what method
with what headers/body should be used to get VR45.67 (revision 67 of
versioned resource 45) into a configuration? Similarly, how is the
currently selected resource at http://foo.com/index.html added to some
configuration?
<jra>
Here's what was in my notes from the last (Concord) design team meeting:
"The current protocol does not specify a method for adding or removing a
revision to/from a configuration. Consider using BIND to put a revision in a
configuration. The BIND puts an entry in the DAV:roots property and puts the
selected revision in the configuration. Putting a collection into the
configuration recursively puts all its members into the configuration but only
adds one entry to the DAV:roots."
We talked about configurations being a specialization of collection, but that
had problems. An alternative is to have it be a resource whose contents are
defined by an XML DTD defining its members. Adding and deleting members would be
editing the contents with GET and PUT. This would also define the meaning of GET
and PUT which are also not currently defined for configurations. I suggest we
take this approach with all resources where WebDAV defines the contents and
resource type. (note an API could implement editing collections in very
different ways if desired.)
</jra>
7) What are the semantics of the DAV:needed-configurations property of
configuraions? Are these needed configs transparently traversed by the
workspace if the parent config is (indirectly) in the RSR? Do I have to
manually add to the needed configs? If so, how do I do that? If it is a
collection, what are the member names? If not, then what? Is it
auto-gen'd at deep checkin time? If that is true, then how does the
server detect that some child (of the root being checked in) has a config
that should be put in the needed list? Is it possible ot have a baseline
of this child automatically created? How does this interact with the
DAV:auto-version revision property?
<jra>
Dependent configurations (and dependent activities) are automatically included
in the workspace RSR when their source revision selector is included. You don't
have to add them. The members of a collection are determined by applying the
workspace revision selection rule, just like any other resource.
</jra>
I suspect that this is an orthogonal concept and that we need another
property on collections which says whether or not they should be
baselined if a parent is being baselined and they have (transitively)
changed since the last baseline.
<jra>
I think a baseline of a member collection of a parent collection is independent
of baselines of its parent. When the parent is baselined, the selected revisions
of its members are added to the resultant configuration. A child collection can
then have a baseline of its own which results in an entirely different and
independent configuration with perhaps very different revisions selected.
</jra>
8) The MKRESOURCE description is confusing in its treatment of existing
resources. As I understand it, any existing resource is, by default,
deleted and the new resource put in its place. If the overwrite header
is specified, the existing resource is somehow morphed into the resource
you want? The last two paras of the section are contradictory. One says
there are no interactions but the existing resource is delete (an
interaction if you ask me) and the next says that the existing one is not
delete but morphed (i.e., an interaction but not a deletion).
<jra>
I hope we stay away from morphing as it is likely to be resource-type dependent
and therefore not easily extensible. MKRESOURCE is used to create new resources
and should not overload DELETE. Perhaps MKRESOURC when the resource exists, like
MKCOL, should return an error and then the user can decide if DELETE followed by
MKRESOURCE is appropriate.
</jra>
9) What resource types can be created with MKRESOURCE? What are the
actual resource type names for our new resources (configuration,
versioned resource, versioned collection, etc.)?
<jra>
Should be able to create any resource type by setting its DAV:resourcetype
property along with any other necessary properties.
</jra>
10) The use of the history-uuid property is not clear. Is it a GUID?
Could/should it be something simpler like a repository-relative id
(i.e., why is it itself universally unique)?
Jeff