Next message: jamsden@us.ibm.com: "Re: working resource DAV:merge-state property?"
Date: Fri, 14 Apr 2000 15:31:18 -0400 (EDT)
Message-Id: <200004141931.PAA15397@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
Its not so much that adding the property adds any particular
complexity, its the implications of having these properties, their
exact meaning, and what it means to support them or not by
different servers. For example, in the cases below:
- empty: and empty body would never be correct unless the target was
already empty. The target of the merge would be a better initial
candidate as it at least has some of the merged contents.
I agree that it would make more sense to make DAV:initial be the
contents of the revision or working resource currently selected
by the workspace.
- something: to get interoperability, will we be forced to say what
gets done for each resource type? I don't think we want to get into
this, but its the kind of issue that can come up.
I agree, but I think it is clear that this should be completely up to
the server since different servers will have different ideas about
what an appropriate value is.
- done: again, the meaning of 'done' may depend on the resource
types, the structure and meaning of their contents, and what it
means to merge. There will be cases where this is easy, and others
where it is impossible. I think the result of a merge always has a
quality component that I'm having trouble fitting in with a
communication protocol.
Since a user reviews the information before checking it in, I don't
think we need to be concerned about being more specific about the
meaning of "done". 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.
Other than not wanting to address these questions now, or delay the
spec in order to resolve them, I'm all for it.
If it turns out to be hard to reach agreement on the semantics of
DAV:merge-state, then I certainly would not want to delay the spec
in order to do so. After taking the change to DAV:initial that Jim
suggests, does anyone have any issues with DAV:merge-state?
Cheers,
Geoff