Re: Versioning spec review - 02.3

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" <gclemm@tantalum.atria.com> on 10/19/99 01:44:03 AM

To:   ietf-dav-versioning@w3.org
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>

Received on Tuesday, 19 October 1999 11:17:16 UTC