Subject: Re: Versioning spec review - 02.3

From: [email-masked]
Date: Tue, 19 Oct 1999 11:15:39 -0400

Geoff,
I would like to personally thank you for the incredibly hard work you have done
on the spec. I know I speak for everyone in the DELTA-V working group when I say
how much we appreciate the effort. But I still don't like repositories!

Some additional comments below in <jra> tags.

"Geoffrey M. Clemm" <[email-masked]> on 10/19/99 01:44:03 AM

To:   [email-masked]
cc:

Subject:  Re: Versioning spec review - 02.3

   Also, core is described as providing versioning of largely independent
   resources. Independent with respect to what? Most web applications are highly
   linked resources, so this level of versioning by implication isn't
particularly
   useful. What exactly is meant by this statement? I think independent in this
   case refers at least in part to independent changes in the resources, not
   necessarily just independent resources.

Core versioning does not provide baselines, activities, or versioned resources.
Web resources may be highly linked, but core versioning doesn't give you
anything in particular to version control those links.
<jra>
Again, I think the important thing is that the resources don't need to be
independent, its the changes made to them that are not supported by core
versioning alone, and therefore these changes should be largely independent. I
think the paragraph is just a little missleading, and focuses on the wrong
issue.
</jra>

   Last paragraph: How about using components of versioning support instead of
   "levels"?

"Components" is so over-used these days, that I hate to add another meaning.
<jra>
But they aren't levels. They are mostly independent features. How about
"features" or "versioning functions"?
</jra>

   1.2, Versionable Resource: Might want to put what it means to place a null
   resource under version control. Does it become a resource with an empty body?

That's a little hard, since what if you intended for it to be a collection?
Do we just disallow putting a null resource under version control (for a
similar reason that I advocate not supporting null locks :-)
<jra>
I don't see why it is necessary for a null resource to be versionable, and we
should disallow it.
</jra>

   Does a server have to support immutable
   revisions? Last paragraph says mutable revision support is optional, but
doesn't
   say anything about immutable revisions.

A server doesn't do anything special to support immutable revisions, other than
failing an attempt to use DAV:overwrite as a DAV:checkin-option.  So basically
supporting mutable revisions is supporting the DAV:overwrite option.
<jra>
What I was asking has to do it IMmutable support. Can a server support ONLY
mutable resources, or does it have to have support for immutable resources too?
For example, DMS systems that don't currently support immutable revisions. In
this case, the DAV:overwrite would always be T. B.T.W., this isn't mentioned in
the semantics of CHECKIN. Looks like mutable revisions are missing from CHECKIN
although the postconditions mentions the concept.
</jra>

   3.6.1: The revision selector for a baseline would have to include the URL of
the
   associated collection, and the baseline id. A baseline is the only revision
   selector that has a compound name. This will complicate the revision
selection
   rules.

No need for a collection/id pair.  Just use the URL to that baseline.
<jra>
What is the URL for the baseline? Is it something the server generated, or is it
derived from the associated collection. The protocol doesn't say how a baseline
is created, or how this URL is derived. Did I miss this? I don't see anything in
CHECKIN.

In any case, any place where a specific revision is required, but revision id
must be specified. For example, putting a configuration in the RSR. The same
must be true of baselines.
</jra>

   3.7.3: doesn't every baseline have to have a corresponding revision of the
   versioned collection?

I'm not sure what you mean by "corresponding".  Every baseline has to select
a revision of its versioned collection, but several baselines of a versioned
collection can select the same revision of that versioned collection.
<jra>
Right. This is fine.
</jra>

   3.7.4 Need more control over merge. To ensure semantics, should use a MERGE
   method instead of directly editing properties which are likely live and not
the
   implementation of persistence for the merge successor/predecessors.

Added constraint that only appropriate revisions can be added to the
collection.  How is constraining a "property collection" any harder than
constraining a method.  You write down the constraint, and servers and
clients must follow it.
<jra>
A method can define specific semantics that are supported. It doesn't have to
list a bunch of things you can't specify.
</jra>

   3.8.2: rsr-baseline: must have the URL for the collection and the id of the
   baseline. A baseline is like a revision and must be addressed by its id.

See above.  A baseline has a URL, and can be addressed by that.
<jra>
Again, I don't know what this URL is or how it was created.
</jra>

   General question on the introduction of conflicts in the RSR: many of the
   revision selectors indicate they don't ever create conflicts, or only create
   conflicts in certain circumstances. Aren't conflicts created not by a
particular
   revision selector, but by the presence of more than one revision selector in
the
   RSR, each of which might pick a revision that is not on the same line of
   descent?

Yes, but only for the DAV:rsr-merge operator (or for DAV:needed-activities).
The DAV:rsr-or operator just does "first match".
<jra>
Then the statements that these things never create conflicts is missleading and
needs clarification.
</jra>

   rsr-configuration: this one is a problem as the RSR must be used to select
the
   revision of the configuration that the RSR uses to see if the configuration
   contains a revision of the target resource. Since configurations can't
contain
   configurations, this isn't a problem, but it may have undesirable
implementation
   consequences. The configuration used by the RSR can change without anything
   changing in the RSR itself. Say the configuration selected is one labeled
Foo,
   and Foo moves to a different configuration. Perhaps we need to restrict a
   revision selector to a revision of a configuration, just like baselines.
   Whenever a specific revision is required, the workspace isn't used, and a
   specific id is required. Can't use a label because that could move.

Added constraint that a versioned-configuration cannot be used, but a
configuration revision can be.
<jra>
It was always a configuration revision, the issue was how that revision was
specified. So you mean by the constraint you added that you have to specify a
particular revision with a revision, not just the URL letting the workspace pick
a revision? Note it would be OK to use a workspace or label to find the correct
configuration to put in the RSR, but what actually gets stored must be the
specific selected revision, and this can't change just because the workspace
changes (in an unrelated way), or labels get moved. I think what this means is
the RSR must be reported with specific revisions using the revision id, not
labels.
</jra>

   4.5 Seems like it should be OK to copy:
   workspace: it would be a new workspace with the same RSR, but none of the
   working resources
   activity: it would just create a new activity with some of the properties
copied
   configuration: should work fine

I think it would be misleading and not that useful to support a copy
that cannot copy the key properties of the resource.
<jra>
Agree, but such restrictions point to a problem in the protocol semantics. We
can just let the copy happen even though it isn't that useful in some
circumstances.
</jra>

   This doesn't seem
   consistent with lock. Lock is a dynamic access control mechanism. Locking a
   versioned resource should be the same as setting the single-checkout
property.

checking it out in the default workspace has the right semantics for down level
clients working against auto-versioned resources ... the PUT that would auto-
version fails because the resource is already checked out into the default
workspace.
<jra>
Nice idea, but I think it overloads lock too much. Another way to look at it
(from the point of view of a non-versioning aware client) is the lock prevents
anyone else from checking out the revision. So the down-level client locks, does
a bunch of PUTs knowing that no-one else can change the resource, and then does
an unlock. Each PUT still does a CHECKOUT/PUT/CHECKIN, but only the down-level
client can directly or indirectly checkout the revision. The effect is the same,
but this keeps lock out of checkout/checkin which might be a good thing.
</jra>

   Only the lock owner can do the checkout. Lock on a revision does the same
thing
   for the revision. Lock on a workspace prevents any checkouts in that
workspace
   (because only the lock owner can update the properties), etc. These are the
   semantics from the model introduction I think.

I think these metadata items want ACL's, not lock tokens.  But I've added
it to the issues list in any case.
<jra>
Lock is an access control mechanism. We've already got the method and need to
have it mean something. This is just an attempt to do something reasonable. If
we want to keep locking optional though, we'll have to make sure none of this
functionality is required.
</jra>

   4.11 OPTIONS is on the resource too, not just the server. I hope the client
   doesn't need to know repositories on the server.

I think this is the repository question again? (:-)
<jra>
The details may be related to the repository, but a server could support
versioning on one resource, and not another. So these new OPTIONS, like all HTTP
options, need to be on the resource too.
</jra>

   The preconditions should be specified more logically too. For example, If the
   DAV:single-checkout property of the selected versioned resource is set, the
   resource must not be already checked out in any other workspace.

I'd be concerned that that would turns something very concrete that
you can verify into a vaguer statement that might be misunderstood.
We should discuss this.  I could be argued into it.
<jra>
Concrete is good, but the gap between the semantics in the scenarios and the
introduction is pretty wide. I'm not suggesting we remove the precise
descriptions, only that we add what they mean.
</jra>

   Last
   precondition: a revision cannot be checked out twice in the same workspace.

That is implied by the fact that you can't apply CHECKOUT to a working
resource.
<jra>
Exactly, but it takes a lot of mental energy to figure this out in some cases.
</jra>

   Marshalling, how is the Target-Selector overridden with a specific label or
id?

It isn't.  The Target-Selector with a label or id is just for folks with
lightweight workspaces that don't have rsr's.  For folks with workspaces,
overriding with a specific label is far less common, and can be done by
accessing the DAV:revisions or DAV:revision-labels collections.
<jra>
Two problems: if the Target-Selector is just a label, what is used to select the
collection revisions in the URL path? Second, folks with workspaces will
override with a specific label LOTS of times to do compares, browse old
versions, prepare for merging, look at what other people are doing, etc.
</jra>

   We need the Target-Selector to specify the workspace for collections in the
URL
   path, while overriding the Target-Selector for the leaf element of the path.

We could do that, but I argue we don't "need" to do it.
<jra>
I don't know how it would work without this capability. What revision of the
collections would be used?
</jra>

   Result: the checkout response must be in a multistatus, not just a response
   element.

To handle the property update?
<jra>
The DTD for WebDAV shows a DAV:response in a DAV:multistatus, never by itself.
</jra>

   Again, CHECKIN is doing PROPPATCH work. This is not a propertyupdate, its a
set
   of parameters for the CHECKIN method. We should not reuse the propertyupdate,
   but rather create a new element, specific to the method. Otherwise we have to
   specify a whole bunch of restrictions about what can go in the
propertyupdate.

I don't think we need to put on any restrictions.  This seems like a pretty
natural place to allow you to specify CHECKIN options, but I could go either
way.
<jra>
I don't think we need two ways of updating properties on a resource, PROPPATCH
and CHECKIN. You say later on that some of the properties are not actually
saved. This is even worse. Method parameters should be coupled with the method,
not the resource.
</jra>

   DAV:uncheckout is a control couple. This is not good style. Use a separate
   method. There's no reason to conserve them. Control couples appear to make
the
   protocol smaller, but they really add complexity.

Not if they are logically very similar in basic intent (i.e. "I'm done
with this resource").  We already have DAV:overwrite which doesn't create
a new revision, and DAV:identical-uncheckout which only creates a new
revision if it has changed, so DAV:uncheckout seems to fit in very smoothly.
<jra>
But I think the intent of the two methods is the exact opposite. The intent of
CHECKIN is to create a new revision an preserve changes unless perhaps there's
no need to because there were no changes. The intent of UNCHECKOUT is to ensure
a new revision is not created, and the changes are lost. Coupling these two
concepts in the same method seems wrong. This is taking control couples too far.
</jra>

   Notice that most of these
   checkin policies could be marshalled in simple headers.

So we could use up the single header namespace, instead of using XML
which has user-defined namespaces ? (:-)
<jra>
Since we own headers, there is no namespace issue. Users can't easily add
headers without extending the protocol. There is always a tension between using
headers and using entity request bodies for marshalling arguments. The WebDAV
spec has a good rational for how this is done in WebDAV, section 1 under
Namespace Operations. I think there is an opportunity to simplify the protocol
by using headers instead of entity request bodies in some cases. It isn't
important to do this now though. We can make a protocol optimization pass after
we get all the methods done.
</jra>

   7. The paragraph about Target-Selector specfies a revision id or label is
   incorrect. The selector "self" cannot be applied to collections on the path
   because its a revision of the collection that's needed, not the versioned
   collection as a whole.

And if so, it will "correctly" return an error (you should be using a workspace
to look at things in versioned collections).
<jra>
But down-level clients can't do this.
</jra>

<jra>
I'll include some locking semantics in another message.
</jra>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Mon, 25 Oct 1999 17:41:31 -0400

From: [email-masked]

In the latest rev of the spec, the versioning options fell quite naturally
into 3 levels, so given the client-side advantages of having 3 levels of
support vs. multiple orthogonal versioning options, I'd like to go with
levels, if at all possible.

   <jra>
   Can a server support ONLY mutable resources, or does it have to have
   support for immutable resources too?

I assume by support for immutable resources, you mean providing a
client with some way of saying "never allow a DAV:overwrite on this
revision".  To me, that's an access control issue, not a versioning
issue, and I'd rather not mix in limited forms of access control
that will just end up conflicting with the general forms when they
are provided.  Since neither DMS nor CM systems provide this functionality
on a resource by resource basis, we gain no interoperability by 
specifying it.

   For example, DMS systems that
   don't currently support immutable revisions. In this case, the
   DAV:overwrite would always be T.

A DMS must let you do a checkin with DAV:overwrite=F (otherwise
you'd never have more than the initial version).  The only difference
in this regard between a DMS system and a standard CM system is that a
DMS system allows you have DAV:overwrite=T, which a standard CM system
would refuse.

   B.T.W., this isn't mentioned in the
   semantics of CHECKIN. Looks like mutable revisions are missing from
   CHECKIN although the postconditions mentions the concept.

Do you mean something like "If DAV:overwrite=T then the server MUST
support DAV:overwrite having the value T"? (:-) 

   <jra> What is the URL for the baseline? Is it something the server
   generated, or is it derived from the associated collection.

All baselines for a particular versioned collection can be found in
the DAV:baselines collection of that versioned collection.  The
server generates the URL of that collection, and generates the
name for a baseline in that collection. 

   The
   protocol doesn't say how a baseline is created, or how this URL is
   derived. Did I miss this? I don't see anything in CHECKIN.

I took that out, since I agree with your contention that it doesn't properly
belong in CHECKIN.  So you now just create baselines with the MKRESOURCE
command.  There's a ToDo note in the draft saying this should be explicitly
mentioned in the MKRESOURCE method description.

   In any case, any place where a specific revision is required, but
   revision id must be specified. For example, putting a configuration in
   the RSR. The same must be true of baselines.

Baselines and revisions are indicated in RSR's by their URL's.  We
could allow alternative compound notations as well, but is there
a compelling reason to do so (it does add complexity).

   How is constraining a "property collection" any harder than
   constraining a method?  You write down the constraint, and servers and
   clients must follow it.

   <jra> A method can define specific semantics that are supported. It
   doesn't have to list a bunch of things you can't specify.
   </jra>

I had no trouble specifying the appropriate constraints on the
appropriate properties in the protocol.  Live properties commonly have
their values constrained by the server, so this is nothing unusual for
WebDAV.

   having a downlevel lock check out the resource into the default
   workspace has the right semantics for down level clients working
   against auto-versioned resources ... the PUT that would auto- version
   fails because the resource is already checked out into the default
   workspace.

   <jra> Nice idea, but I think it overloads lock too much. Another
   way to look at it (from the point of view of a non-versioning aware
   client) is the lock prevents anyone else from checking out the
   revision. So the down-level client locks, does a bunch of PUTs knowing
   that no-one else can change the resource, and then does an
   unlock. Each PUT still does a CHECKOUT/PUT/CHECKIN, but only the
   down-level client can directly or indirectly checkout the
   revision. The effect is the same, but this keeps lock out of
   checkout/checkin which might be a good thing.
   </jra>

One of the bad things about creating a new revision on every downlevel
PUT is that it fills the history of a resource with "non-interesting"
revisions, but we have to do it to prevent lost updates.  In contrast,
a LOCK/UNLOCK request gives us exactly the information we need to
implement a more intelligent revision creation policy.  To not take
advantage of this information when designing the protocol strikes me
as remiss.

   <jra>
   Lock is an access control mechanism. We've already got the method and
   need to have it mean something. This is just an attempt to do
   something reasonable. If we want to keep locking optional though,
   we'll have to make sure none of this functionality is required.
   </jra>

Current WebDAV locking (with lock tokens) are good for some things,
but any time it is not reasonable to expect a client to hold and
remember a lock token, WebDAV locks are not appropriate.  It is better
to just have the protocol treat the operation as undefined or an
error, rather than increase the complexity of the protocol (and of
servers that implement it) with functionality that is not useful.

   Marshalling, how is the Target-Selector overridden with a
   specific label or id?

   <jra>
   Two problems: if the Target-Selector is just a label, what is used to
   select the collection revisions in the URL path?

Core and Activity versioning servers will not be generating versioned
collections, so there will be no collection revisions in the URL path.
Versioned-Collection servers will provide repositories, which are
required to be located in a non-versioned part of the namespace
(i.e. under no versioned collections).  In either case, the DAV:revision-labels
collection will have no collection revisions in its URL path, so no
collection revision selection is required.

   Second, folks with
   workspaces will override with a specific label LOTS of times to do
   compares, browse old versions, prepare for merging, look at what other
   people are doing, etc.

The DAV:revision-labels collection is there to give clients easy access
to any revision by using a label.  No need for a specific header, and
suitable for use in any context where a URL can be specified (as opposed
to the Target-Selector, which just works for a Request-URL).

   CHECKIN is doing PROPPATCH work. This is not a propertyupdate, its a
   set of parameters for the CHECKIN method. We should not reuse the
   propertyupdate, but rather create a new element, specific to the
   method. Otherwise we have to specify a whole bunch of restrictions
   about what can go in the propertyupdate.

Not if we place no restrictions on what can go in the property-update.
Note that I'm happy to say no specification of the DAV:checkin-policy
in a CHECKOUT request, but if we *do* allow it, I believe that the
most appropriate way is to allow CHECKOUT to do an arbitrary PROPPATCH
to "initialize" the new working resource.  Think of CHECKOUT as a
"MKRESOURCE" for working resources.

   I don't think we need two ways of updating properties on a resource,
   PROPPATCH and CHECKIN. You say later on that some of the properties
   are not actually saved. This is even worse. Method parameters should
   be coupled with the method, not the resource.

We already have two: PROPATCH and MKRESOURCE.  So if we add a third,
there is at least precedent.

   Having "uncheckout" as an option to CHECKIN is reasonable because
   they are logically very similar in basic intent (i.e. "I'm done
   with this resource").  We already have DAV:overwrite which doesn't create
   a new revision, and DAV:identical-uncheckout which only creates a new
   revision if it has changed, so DAV:uncheckout seems to fit in very smoothly.

   <jra> But I think the intent of the two methods is the exact
   opposite. The intent of CHECKIN is to create a new revision an
   preserve changes unless perhaps there's no need to because there were
   no changes. The intent of UNCHECKOUT is to ensure a new revision is
   not created, and the changes are lost. Coupling these two concepts in
   the same method seems wrong. This is taking control couples too far.

Both DAV:overwrite and DAV:indentical-uncheckout conflict with your
description of the intent of CHECKIN.  One never creates a new revision,
and the other only sometimes creates a new revision.

   <jra> Since we own headers, there is no namespace issue.

This "we" is a very diverse group (i.e. everyone proposing extensions
to HTTP) with overlapping needs/interests.  Using up a name that is
"global" to this group is, in my opinion, a very significant issue.
After all, we've already made life difficult for the archery extension
group by defining the semantics of "Target-Selector" (:-).

   <jra>

Down-level clients won't be issuing requests with Target-Selector headers.

Cheers,
Geoff