Next message: jamsden@us.ibm.com: "Re: Versioning TeleConf Agenda, 6/5/00 (Monday) 2pm-3pm EST"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256907.0063D88B.00@d54mta02.raleigh.ibm.com>
Date: Fri, 23 Jun 2000 14:10:33 -0400
Subject: Re: Versioning TeleConf Agenda, 6/5/00 (Monday) 2pm-3pm EST
My comments in <jra> tags...
Minutes:
Attending: Tim Ellison (OTI), Michael ? (OTI), Henry Harbury (Merant)
Jim Whitehead (USC), Jim Doubek (Macromedia), Geoff Clemm
(Rational)
Agenda:
- Which requests are required to handle Target-Selector or
Workspace headers? In particular, does LOCK/UNLOCK?
We only discussed LOCK/UNLOCK. The group agreed that is
appropriate for LOCK/UNLOCK to disallow the Target-Selector or
Workspace headers. Since we now have URL's for all resources
(i.e. versioned resources, working resources, revisions, and
history resources), there is a URL suitable for passing to
LOCK/UNLOCK. In addition to simplifying the protocol, it allows
us to leave the locking protocol alone (otherwise we would have
to extend the lock state to include the value of the Target-Selector
and Workspace headers that were passed in with the LOCK request,
and define what the effect of this additional lock state is on
the semantics of locks).
Please send mail to the group if you agree/disagree with this
approach.
<jra>
Yet more special cases for LOCK and UNLOCK. Could you enumerate the issues
this resolves? I some sense it complicates the protocol by requiring
special handling of locking methods.
</jra>
- Since we have working resource URL's and revision URL's
do we still need working resource id's or revision id's?
This has been discussed on the list recently.
The group agreed that we do not need to require the server
to provide two different server-defined strings for either
a working resource or a revision. Since a URL is more useful
to the protocol than an id (it can be used by itself while
and id requires a versioned resource URL and a header),
it is appropriate to only require that the server provide the URL.
<jra>
This is fine, but it presents a somewhat confusing versioning model. Simply
stated, that model would be: A VersionedResource has many Revisions. A
VersionedResource is identified by its versioned resource URL (at least
from the user's view. Actually the VersionedResource "object identifier" is
server defined and the server maps the versioned resource URL to the object
identifier in some server-defined way). Revisions can have many labels
which uniquely distinguish one revision from another of the same
VersionedResource. So Revisions are ID dependent on their corresponding
VersionedResource. However, the Revision also has an object identifier of
its own which is mapped to some server-generated URL, one that is not
necessarily in the DAV namespace (meaning collection semantics might not
work on the URL segments). So the Revision is not ID dependent on the
corresponding VersionedResource, and there are two ways to refer to a
Revision, with the versioned resource URL and a Target-Selector, and with a
server-generated URL. Clients will have to be aware of then they can/have
to use one approach over another.
</jra>
- Should a Target-Selector header contain anything other
than a label?
Since we have history URL's we don't need the "versioned-resource"
Target-Selector value. If we don't have working resource id's or
revision id's, the only thing left are labels.
<jra>
I always thought of a Target-Selector as something that along with a
versioned resource URL, referenced a specific revision of the identified
versioned resource. There are lots of things that identify a specific
revision:
- labels
- current revision or working resource in a workspace
- the latest in an activity
- the one in a baseline or configuration
When one is just browsing around the versioned resource space looking at
revisions, seeing how they changed by looking at the comment property or
comparing them with a diff tool, seeing who changed them and when, etc., it
would seem useful to be able to use any of these identification mechanisms
to specify which revision you want to see. For example, assume the is an
activity /webdav/versioning/activities/4.0/protocolUpdates that represents
the changes made in the protocol to update it to locigical version 4.0.
Then one might access the latest revision in that activity with:
GET /webdav/versioning/draftSpecification.doc
Target-Selector: /webdav/versioning/activities/4.0/protocolUpdates
The server knows that the Target-Selector specified an activity, and could
go get the latest revision in that activity, that is, the one that would be
the source or a merge. A client could use this to say browse the changes
made in the activity before attempting to do the merge.
The current proposal seems to be requiring clients to use server-generated
URLs for everything but labeled revisions. This seems unfortunate because
it encourages/requires the use of identifiers that have no human meaning.
</jra>
- Should checkout/checkin in a workspace be modeled as
a state change of a versioned resource, or as the
replacement of a versioned resource with a working resource
followed by the replacement of a working resource with
a versioned resource.
We spent most of the hour talking about the last item. The group agreed
that this change requires further discussion. In particular, the reasons
for making this change need to be clearly spelled out and mailed to
the list (Geoff agreed to do so), the effect of this change on the
protocol needs to be clearly identified (Geoff agreed to do this also).
<jra>
I assume you mean replacement of a *revision* of a versioned resource with
a working resource...? It seems from the usual semantics of
checkout/checkin that the state of both the versioned resource and the
workspace are changed. The versioned resource has a new revision which
changes its revision history by adding a new predecessor/successor
relationship. In reality, only the revision may be updated as its the only
place the new successor must be added. All other properties can be
calculated. Of course there could be other implementations. The workspace
on the other hand has members that it selects. Checkout and checkin changes
these members. Can we specify the semantics of what happens without
specifying how? For example, on checkout, the workspace will select the
resulting working resource (doesn't matter who's state changed). On
checkin, the workspace selects the newly created revision.
</jra>
Cheers,
Geoff