Next message: Jim Doubek: "RE: DAV:revisions property for a workspace resource"
Date: Fri, 14 Apr 2000 17:18:26 -0400 (EDT)
Message-Id: <200004142118.RAA15467@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: working resource DAV:merge-state property?
From: jamsden@us.ibm.com
On the question of what the server places in a working resource with
DAV:intermediate or DAV:done merge state:
<jra> But I don't think its up to the server. The problem is that
this is resource type dependent. There's no way to get
interoperability without tying resource types to the protocol. I
guess we could consider what it would mean to ignore the
interoperability issue here and let servers advertise what they
do. But a client merging from server to server wouldn't know what
to expect. This is the stuff that makes me nervous. </jra>
The user is going to be reviewing the contents of the working resource
before checking it in anyway, so we can count on human intelligence
deciding whether the merge is good or not. So I see no
interoperability problem in having different servers come up with
different default/initial/proposed merges.
All I have in mind here is that automatic merge algorithms usually
distinguish a "trivial merge" that might be OK as it is, and a
"conflict" which is known to require human intervention. A server
used DAV:done and DAV:intermediate to distinguish those two cases.
DAV:initial means that the server has no clue about how to merge a
resource of that type.
<jra> This makes a lot of sense. How about more descriptive terms
like DAV:merge-completed, DAV:merge-partially-completed, and
DAV:no-server-conflict-resolution? I know they're long, but we need
to be clear about their meaning. </jra>
I'm pretty mellow about terminology, but I'd prefer something a bit
shorter and easier to remember. Somebody is going to look this up
in the protocol definition before writing a client anyway, so I don't
think we need to squeeze a full definition into the property name.
Cheers,
Geoff