Re: Versioning spec review - 02.3
jamsden@us.ibm.com
Wed, 27 Oct 1999 10:13:04 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256817.004E2D09.00@d54mta03.raleigh.ibm.com>
Date: Wed, 27 Oct 1999 10:13:04 -0400
Subject: Re: Versioning spec review - 02.3
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on 10/27/99 01:22:29 AM
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: Versioning spec review - 02.3
From: jamsden@us.ibm.com
<jra>
We went to a lot of trouble trying to establish levels only to eliminate
the concept in Concord. It seems too bad to reintroduce them now. I hope
we
don't go over that same ground again. I wasn't helpful getting the
versioning semantics down.
</jra>
I assume you meant "It wasn't helpful ..." (:-).
I believe the reasons why levels are preferable to options still are valid.
If the protocol now displays some natural leveling after recent iterations,
I think it is important that we recognize and take advantage of it.
<jra>
No, I meant I wasn't helpful! Boy the things that slip by when you're in a
hurry...
</jra>
<jra>
... we need to say that the server can fail the operation or
overwrite the revision. I don't remember seeing this in the
postconditions
of CHECKIN.
</jra>
The postconditions are the state you reach after successful completion
of the operation. If the operation is aborted, then the postconditions
will not hold. This is true for all the postconditions, not just the
DAV:overwrite one.
<jra>
Ok, I didn't see it in the preconditions either.
</jra>
<jra>
So baselines don't have human meaningful names or labels? How will a
user
distinguish one fron another?
</jra>
A client is free to give them various properties to identify them.
We could standardize on some of these, but I tend to dislike enumerating
dead properties (even interesting ones) in the protocol. Perhaps
we could have some companion document (and move DAV:comment and DAV:author
into it)?
<jra>
This sounds too ugly. I wouldn't use baselines. Instead, I would create a
configuration with a name I know in a collection I createds, and put the
versioned collection and all it members into the configuration. That's the
same thing as a baseline, but it has a name I recognize and has something
to do the the project/release/deployment I'm doing. The only thing missing
that baselines provide is a way for the collection to keep a list of such
configurations. I claim that clients are free to add properties to
collections as they wish, and these configurations could be added as hrefs
if the client wants them. To achieve interoperability, we might want to
specify a DAV:baselines property as the recommended place to put such
configurations, but I'd like to see the use cases that require this. So, I
think I'm back to our original discussion over lunch in Cary, do we really
need baselines? Will configurations do?
</jra>
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.
<jra>
I don't recall MKRESOURCE mentioning creating baselines, or the
semantics
of how one was created.
That's why it's a "ToDo" note (:-).
Does the collection have to be checked in? Can it
have working resources in this or any other workspace?
<jra>
This is another example of method overload. There are a lot of semantics
that must be checked to create a baseline. Its not just initializing some
properties of a new resource type. MKRESOURCE will get pretty complicated
if each new resource type it creates has to describe a bunch of special
case additional semantics. I vote for a new method.
</jra>
<jra>
So the human meaningful name (its human URL and revision id) for a
revision
can't be used in the RSR?
That's my vote. As fun as RSR's are (:-), I see them as a client artifact,
not a user artifact.
<jra>
I think human meaningful names should be the rule, not server generated
URLs. It is the server's responsibility to map URLs to resources, not the
client.
</jra>
<jra>
If you have a bunch of versioned collections in a
hierarchy, and you want to access a specific revision of a member of one
of
them, then you need two things: the workspace to use to select the righ
revisions of versioned collections along the path, and a revision name
to
select the specific revision of the member versioned resource. We don't
want to require users to us repository and server implemented URLs for
this.
</jra>
You use a PROPFIND with the workspace as the target selector to get
the DAV:revisions property of the DAV:versioned-resource property of
the revision. With the DAV:revisions collection, you can select any
revision of that versioned resource that you want.
<jra>
Completely unacceptible. Again, it is the server's responsibility to do
this name mapping, not the client. That's why we have human meaningful
names.
</jra>
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).
<jra>
It is not acceptible to require clients to translate URL and revision
names
into server generated revision URLs for this operation. The client
should
always be able to use the name they know a revision by to access that
revision.
</jra>
I'm not sure what you mean by "translate URL and revision names into
server generated revision URL's". If you mean, concatenate the
DAV:labeled-revisions URL with a "/" and a label, then I find that
totally acceptable. That's exactly what a client does for a user whenever
a specific member of a collection is requested.
<jra>
What I'm saying is that it is unacceptible for the client to have to do a
PROPFIND, get a server URL and hand it back. So what I want to do is have
the client give the server a workspace for resolving URL path segments,
with an option to provide a revision name to override the selection of the
last item in the path.
But I see how your approach would work too.
</jra>