Next message: Jim Doubek: "RE: Resource vs. Revision Properties"
To: ietf-dav-versioning@w3.org
Message-ID: <OF1F85ED1C.75F3ED1B-ON852568D2.004721D8@ott.oti.com>
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Date: Mon, 1 May 2000 09:15:55 -0400
Subject: Re: Resource vs. Revision Properties
<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>
<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
<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>