Next message: Geoffrey M. Clemm: "Re: Resource vs. Revision Properties"
To: ietf-dav-versioning@w3.org
Message-ID: <OFE0E01C60.53494F34-ON852568D2.005ADB6A@ott.oti.com>
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Date: Mon, 1 May 2000 12:46:48 -0400
Subject: RE: Resource vs. Revision Properties
Jim, see <tim_2> tags below...
Regards,
Tim
...snip...
<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>
<tim_2>
A versioning unaware client would always be dealing with the target of the
request URI, which will be a revision/working resource for a versioned
resource.
</tim_2>
...snip...
<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>
<tim_2 weasel="on">
Depends upon the functionality that is desirable. My understanding is that
it intended to prevent >1 working resource for a given versioned resource,
and thereby avoid the merging problem (i.e., serialize updates).
However, this property pre-dates me, so I'll leave it up to one of the
protocol doc authors to defend it ;-)
As a potential client, DAV:single-checkout is more interesting to me since
it avoids merging problems. As a potential server, DAV:linear is more
interesting, since I can use it to implement DAV on a non-branching store.
<tim_2>