Next message: jamsden@us.ibm.com: "Re: Resource vs. Revision Properties"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568E6.0081BC7D.00@d54mta02.raleigh.ibm.com>
Date: Fri, 19 May 2000 18:52:10 -0400
Subject: RE: draft-ietf-deltav04.5 now available
Here are some comments from my reading of 4.5:
- 3.3: I don't think we should do this -- it will impact
down-level clients by seeing a type they don't understand.
We should add a new property to indicate it is versioned.
<jra>
Clients will always be seeing things they don't understand from the Web.
The convention is to ignore what you don't understand. This would work fine
for versioned resources.
</jra>
- 3.3.4: It isn't "linear" -- it is exclusive/non-exclusive
or reserved/un-reserved that we are talking about.
<jra>
Agree
</jra>
- 3.4.3: I wish we could separate the linear successor from
the merge successors.
<jra>
I've been in favor of this too. It seems there is a qualitive difference
between what you checked out and changed, and what got merged. This is
information we shouldn't loose.
</jra>
- 6.1: It seems wrong to be able to make a resource versioned if
someone else has an exclusive lock on it.
<jra>
Agree
</jra>
- 6.1: Didn't we use to have a depth header on the VERSION method?
<jra>
Might be nice
</jra>
- 6.2.1: I would prefer to see this be a separate method. Also, if
this sepecifies a label, we should allow a depth header.
<jra>
I think set-target is a bit overloaded and has a lot of control coupling.
</jra>
- 6.2.2: We should allow a depth header on setting labels.
<jra>
agree
</jra>
- 6.5: What does it mean to delete a working resource? Is this an
"UNCHECKOUT"?
<jra>
could fail in order to ensure uncheckout semantics are performed?
</jra>
- 7.1: In reading this it is really wierd to make a workspace a
versioned resource. I understand the desire to re-use concepts,
but it is strange that I "checkout" a revision of a versioned
resource and get a versioned resource not a working resource. I
think we should separate Workspaces and Baselines to use different
methods so that the concepts are separate.
<jra>
What checkout produces a versioned resource?
</jra>
- 8.3: Can SET-TARGET cause merge conflicts? This space can be
very messy to do in a fully interopable way.
<jra>
Good question. I think workspaces should only be populated with merge.
</jra>
- 8.5: I'm not sure what is meant by a "versioned collection". Does
changing the contents create a new version? If so, then I think
we need to consider an intermediate level. That is, I should be
able to have a "versioned collection" that tracks its properties
and changes to them, but not necesarrily its children.
<jra>
Changing the members or properties of a versioned collection should be done
on a working revision of the versioned collection. We shouldn't separate
properties from "contents" which for versioned collections are its members.
</jra>
- 9.3.7: I'm not sure I understand what this property is for...
<jra>
Me either. Looks like a copy/paste error.
</jra>
- 9.4.2: I think this needs to be optional -- I can see server
supporting activities, but this is more complex.
<jra>
Not really. All the work is already done. Its just iterating over a set
instead of a single activity.
</jra>
- 10.1: Why don't we fold this header into Target-Selector?
<jra>
We need Target-Selector to override the workspace for the leaf resource.
</jra>
Chris