Re: Continuation of comments on versioning draft -09

   From: "Lisa Dusseault" <lisa@xythos.com>

   If you decide to keep LABEL, changed or unchanged, I think it will only be
   useful as an advanced versioning feature, where it might work better in
   conjunction with workspaces...  please, please do not require "core" support
   for LABEL.

In advanced versioning, it is much more likely that a server will
support baselines, and not try to fake it with labels.  So labels
are primarily there for core versioning servers that don't want
to implement baselines.

Note that your server can do what it wants, e.g. expose the DAV:version-name
as a label, and fail all explicit client attempts to use the LABEL method.
The only interoperability cost that you would incur would be that
a client would then not be able to label against your server.  But
it would be able to checkout/checkin and all the other usual core
versioning things.  

   Section 11.2: DAV:successor-report
   Must this be supported by core versioning?  With single-line-of-descent
   versioning, I would think that this report wouldn't be particularly useful,
   and would just be extra work.

You need this report (actually, it is now a property)
to get a URL for the version that is the successor.

   Section 11.3 DAV:checkout-report
   Must this be supported by servers that only allow a single checkout to the
   same URL as the version selector?  With a server that simple, all a user
   needs to do is find out if the resource is currently checked out to get all
   the information they would out of this report.

Just knowing that a version is checked out doesn't tell you anything
about the current state of that checked out resource (i.e. it's
current content or properties or location).  Especially if the checked
out resource is a working resource, it might be hard to find it otherwise.

   Speaking of which, how do I find out who checked out a resource?

By looking at the DAV:creator-displayname of the checked-out resource
(or any other relevant property of the checked-out resource).

   Section 11.4.1
   This example contains a "latest-checkin-report".  The response includes a
   single XML element, DAV:href.  I'd like to see the name of the report
   included in every report, so it would be clearer to the client what it's
   receiving:

In 09, this has been converted to be a live property rather than a
report, so the issue no longer arises.

Also note that it is unclear whether including this in the response
would help a client that didn't know what it just asked for (:-).

   Section 11.5, DAV:version-tree-report
   It does make sense to have this supported by "core".  But, does it have to
   be nested?  The simple and common case will be a single-line-of-descent
   versioning history, which is inefficiently represented as nested.

Inefficiently represented?  Doesn't it just change where the closing
</DAV:version-tree> tags appear?

The purpose of this report is to guarantee that a core client to get
the entire version tree in one request.  It could also do so with a
DAV:property-report, but that report is not required by core.

BTW, I also prefer a list of versions, which is why I prefer the
the DAV:property-report over the DAV:version-tree report, but I
couldn't convince the rest of the design team of this (:-).

   Section 12, Advanced Versioning

   I'd like to admit at this point that I didn't take as close a look at
   Advanced versioning.  I'm primarily concerned with a reasonable set of
   "core" features that can be useful, and _not_ _too_ _confusing_, for normal
   people doing normal document authoring.

In general, we encourage reviewers to skim over the advanced features
to see which ones they are interested in, and then look carefully at
that subset.  In your case, it sounds like that is primarily the
version history resource and the DAV:checkin-fork property.

But reviews on the whole thing are of course much appreciated!

   That said, I do have a few comments.

   Section 12.1, Terms
   In the Baseline diagram -- thanks for which -- do V4 and V6 correspond to
   versions that were created after the creation of the baseline?

Not necessarily.  They are just the versions that happen to be the
targets of the members of the collection that was baselined.

   Please specify whether that is a MUST.

It's not even a SHOULD.  It's just a MAY.

  Can a baseline be created that refers to prior versins?

Yes, just set the targets of the members of your collection
to be the appropriate set of prior versions.

   Section 13.3, Activities, Change Sets and Branches
   The description here of an Activity as a "change set" seems incompatible
   with the description of an activity in "terms" as having only versions on a
   single line of descent.

Why?  A change set would be ambiguous if it had versions on multiple
lines of descent of a single version history.

   Section 13.6, Automatic Version Control
   How does the automatic creation of a versioned resource differ, in the
   response, from the creation of a non-versioned resource?

Not in any way required by the protocol.

   If I, an
   unsuspecting user, try to PUT a resource to a collection and it gets turned
   into a versioned resource immediately, how do I know?

By knowing what repository you are working against ... some versioning
repositories only support versioned resources (i.e. they can't cope
with a mixture of versioned and unversioned resources).

   Otherwise, I might
   turn around and then try to version it!

That's OK.  The VERSION-CONTROL method is specifically defined to be a
no-op in this case, to make life easier for clients.  So in general,
from a protocol perspective, a client doesn't have to care whether a
repository automatically puts things under version control.

   Section 14.2.1, DAV:version-history
   Why isn't this property part of "core", if such complicated things as
   "version-tree-report" are in "core"?

Not being in "core" just means that it is not a required feature
of a versioning server.  In particular, I expect *most* versioning
servers to support the version repository resource.  I personally
have argued that the version history resource should be part of core,
so I'm not the best one to defend it's not being in core (:-).
In particular, I believe Chris Kaler was the primary advocate of
it not being in core.  

   Is the version history totally
   unaccessible from a "core" versioning server?

Being a "core versioning" server just sets the minimum for what you support.
In particular, any server can (and usually will) a significant number of
the advanced versioning properties, methods, and reports.

   I notice there is a DAV:version-history for a version (14.2.1) and for a
   working resource (14.3.1).  Are these the same?  How do they differ?
   Could we have examples of the value of this property, particulary for the
   diagrams that can be seen in section 13.5 or similar?

In 09.1, only a version has a DAV:version-history property.  
If you want to get the version history associated with a
version selector, you would get it from its DAV:target or
DAV:checked-out version (you can get it with one round trip
using the DAV:property-report).

   Section 14.5, Workspace Properties
   How can you definitively tell if a collection is a workspace?

Good point.  I'll add a DAV:workspace property (analogous to
that on a version selector).  Then you can just
check if its DAV:workspace property identifies itself.

   Can I convert a workspace to a collection and vice versa?

No.  You create a workspace with MKWORKSPACE.  You can create
a collection that is a copy of a workspace with the COPY method.

   Section 14.5.1
   Can you convert from a collection to a workspace by adding the
   DAV:current-activity-set property to it?

No.  

   Must DAV:current-activity-set be present if a collection is a workspace?

No (in particular, it would never be present if the server
did not support activities).

   Section 16.10, CHECKIN
   This implies that the merge-set and auto-merge-set must be empty before the
   request can succeed.  How do they get empty?

With PROPPATCH (note that they are not protected properties).

   It's not clear if MERGE is
   supposed to empty those props, or if the user is supposed to manually.

The postconditions of MERGE specify the effect of MERGE on the
merge-set and auto-merge-set.  In particular, it adds values to
these properties, but never removes values.

   Section 17.1, MKWORKSPACE
   I'll suggest in a separate email that MKCOL be used for this...

I believe that the most important part of the definition of a method
is its list of postconditions.  The postconditions of MKWORKSPACE
differ significantly from those of MKCOL, and therefore it would be
inappropriate to use the same method for both.  This is of course
a value call, since "differ significantly" is not a well-defined term.

   Section 17.2, MKACTIVITY
   What does an Activity resource look like ?  What properties does it support?

See the section 14.7: "Activity Properties"

   Does it have a resource type?

Yes, required to be DAV:activity.

   Does it have an owner?

Up to the server.

   Can you delete it?

Up to the server, but if so, you'd use the DELETE method to do so.

   Can you GET it?  Can you PUT it?

See sections 16.2 and 16.2.  Yes, you can, but the result is undefined
by this protocol.

   Can you PROPPATCH it? 

Sure (you can PROPPATCH any resource).

   How about MOVE/COPY?

Up to the server.

   Who has permissions on it?

We'll have to wait for the ACL protocol to answer that question.

   Can you LOCK it?

Sure.

   Can an "Activity" select versions from anywhere? 

Yes (although a versioning server will commonly restrict them
to being from the same repository).

   How does it represent them ?

As members of its DAV:version-set.

   How do you change the set of versions selected by an Activity?

By modifying the DAV:activity-set of a version, which is done
by CHECKIN (or possibly PROPPATCH, if a server allows that).

   Are MKACTIVITY and the corresponding "activity" resource necessary at all?

An activity has several key properties in this protocol, as well as 
all the dead/live properties that a change request
management or activity management system will want to define.

   It seems that an Activity resource only exists so that it can have its URL.
   Well, that seems stupid.

Don't forget the properties (:-).

   The client can easily generate a unique string --
   how about a UUID?  -- and use that for an Activity string.
   A more sensible readable string may even be possible, like
   "lisa@xythos.com,20001002T15:38,myactivity".  Then the user just has to add
   that to the activity-set for everything in that activity.
   This would help reduce the load on the server.

You need a URL to apply a method (such as MERGE) to it,
or to access it's properties (such as its DAV:version-set).

   Otherwise, does the server
   have to check everytime the activity-set is changed, to see if the
   activities are all valid, existing activity resources?

Yes, just like it has to check whenever you update a property of any
other resource (i.e. that there really is such a resource).  (That's
it's job, after all :-).

   Section 17.3, BASELINE-CONTROL
   This is really confused.  I think this needs much more explanation of what
   the model is before it's implementable.  What kinds of resources are you
   supposed to be able to apply this method to?

See the preconditions of the method.  In particular, DAV:must-be-collection.

   What does it do to the resource?

See the postconditions.  It sets the DAV:baseline-selector of the
collection to be a newly created baseline selector.  A baseline selector
selects a baseline from a baseline history, just as a version selector
selects a version from a version history.  This baseline selector
can then be checked out and in to create baselines of the collection.

   Can you have multiple baselines for a single workspace, as the model
   implies?

A workspace can have several members that are baselined collections.
Each of these baselined collections have an associated baseline selector
whose target is a particular baseline.  So in this sense, yes, a single
workspace can have multiple baselines (one from each of the baselined
collection members).

   The model says you can only convert workspaces to baselines, but this
   section says  you can convert collections to baselines.

That was a bug in the 08 draft ... you used to only be able to baseline
a workspace collection, but in 09, this was extended to allow you to
baseline any collection ... in particular, you can have baselined collections
on a server that does not support workspaces.

   The new "baseline selector" resource that is created as a result of this
   request is underspecified.  What is it? What properties does it have?  Can
   you delete it?  What happens if you GET it?  What happens if you PROPFIND
   it?

Good point!  This should have been defined in the advanced versioning
Terminology section.  The answer is that a baseline selector is just a
version selector whose target happens to be a baseline version.  So
its properties and methods are just those of any other version
selector.

   Last comment, refering to no particular section:  I think the draft did a
   bit of a poor division between "core" and "advanced" with the
   "version-history" stuff.  Please take another look at what goes where; most
   of the "version history" properties are specified under "advanced".  thanks.

Chris, would you like to respond to this?  You're our designated "version
history should not be in core" advocate (:-).

   I think that's enough for this mail!

Lisa, I would like to especially thank you for taking the trouble to
look over the advanced sections that probably weren't of direct interest
to your clients or servers!  I will try to post a 9.2 draft that 
contains the fixes/changes based on your comments by the end of the
week.

Cheers,
Geoff

Received on Wednesday, 4 October 2000 15:43:02 UTC