Next message: Tim Ellison/OTT/OTI: "RE: Resource vs. Revision Properties"
From: "Jim Doubek" <jdoubek@macromedia.com>
To: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>, <ietf-dav-versioning@w3.org>
Date: Mon, 1 May 2000 08:21:11 -0700
Message-ID: <NEBBKGCJHMKNLDINHHCEEEKECBAA.jdoubek@macromedia.com>
Subject: RE: Resource vs. Revision Properties
<jimd>
agreed mostly, but see the DAV:linear way below...
</jimd>
<jim D>
I've been working through In version 4.4 of the spec and have some
issues
and questions about properties.
- Section 3.2 Resource Properties
While these props obviously apply to unversioned resources, it's not
clear
from the text how these apply to versioned resources vs. revisions.
</jim D>
<tim>
These properties apply to any resource, (they are defined here to grant
them DAV semantic status for interoperability).
Therefore it is valid to talk about the comment or author of
the versioned
resource and/or a revision of that resource.
</tim>
<jim D>
Here's my reading of the section:
1) For non-versionable and unversioned versionable resources, DAV:author
and
DAV:comment apply to the resource itself, and can be updated
via PROPPATCH
as usual, subject to the normal interactions with locking, permissions,
etc.
<tim/> yes.
2) For versioned versionable resources, DAV:author and
DAV:comment apply
to
the resource itself, and optionally to each revision. I assume one
checks
out a revsion, modifies the working resource prop, and
checks it in to
effect a revsion prop change; it's not clear to me how one
updates the
base
level property.
<tim>
Using the "Request-Target-Selector: versioned-resource" header in the
PROPFIND/PROPPATCH method. See section 4.1.
</tim>
<jimd> ok </jimd>
<jim D>
I would propose that these props be made to act the same as the
body/content
of the resource. That is, they only apply to revisions of a versioned
resource, and can only be changed via PROPPATCH on the
working resource.
You
would also want them to work as does PUT for auto-version resources.
There
would be no author/comment attributes for the versioned
resource itself.
<jim D/>
<tim>
I think an author and comment on the versioned resource is useful, for
example to describe the intent of the resource, and revision
comments would
describe changes-- there are other uses too.
</tim
<jimd>
Which one would a non-versioning aware client see?
</jimd>
<jim D>
- Section 3.3
DAV:linear and DAV:auto-version are both mutable properties
of versioned
resources. How does one set such a property?
</jim D>
<tim>
As above, call PROPPATCH with the Request-Target-Selector:
versioned-resource to select the versioned resource itself
rather than the
revision.
</tim>
<jim D>
Should PROPPATCH apply to the base resource? Does calling
PROPPATCH for
these props on a revision
constitute an error, or is the target implicilty the resource rather
than
the revision?
<jim D>
<tim>
Setting the property on a revision would not be an error, since
revisions
can manage properties that are outside the spec, but they would not have
the desired effect since the server would only be considering
those on the
versioned resource itself.
</tim>
<jim D>
Can one call PROPPATCH on a working resource, and what happens
upon checkin?
</jim D>
<tim>
Yes, you can PROPPATCH a working resource for all properties that are
unprotected. At checkin all properties (except those
explicitly described
in the spec as mutable) are saved in the revision history as
immutable as
the content.
</tim>
<jim D>
I _think_ the answer is that one calls PROPPATCH with the
resource as a
target, and does not checkout/checkin for these resources, but I
couldn't
see that explicitly in the text.
</jim D>
<tim>
I agree it should be written in the text that the versioned resource
properties are not version controlled themselves.
</tim>
<jim D>
- Section 3.3.4 : DAV:linear
This states
<quote>
When the DAV:linear property of a versioned resource is
true, only one
working resource can be checked out from that versioned
resource at any
time, and only the revision that has no successors can be
checked out.
The
default value of DAV:linear is false (F).
</quote>
Since this is mutable, it isn't guaranteed that the resource
is linear
at
the time DAV:linear is set to 'T'. In such a case, there may be more
than
one revision with no successors. I would propose that it be
an error to
set
the prop to true unless the single-tip condition is true.
<jim D>
<tim>
Good point, although I'm not sure that making the history truly
linear was
the intent, it used to be called DAV:single-checkout, which as you point
out is a different requirement.
</tim>
<jimd>
I have 2 concerns:
1) If the revision history is multi-tipped (i.e., there are unmerged working
tips), the revision selection behavior is not deterministic as described.
Which tip is selected?
2) In such a case, the forwardgoing structure still won't be linear, which
seems to be the intent of this property.
OTOH, if a history is non-linear, but the current state is a single tip, the
property works as I believe it's intended - to prevent future bracnhing.
That situation ought to be just fine.
</jimd>