Next message: Geoffrey M. Clemm: "Re: Versioning TeleConf Agenda, 6/5/00 (Monday) 2pm-3pm EST"
Date: Fri, 23 Jun 2000 17:59:47 -0400 (EDT)
Message-Id: <200006232159.RAA29457@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: protocol-04.8 issues
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
The protocol doc. (4.8) description for SET-TARGET (section 6.5) states
that the depth header may be specified.
When depth is set to >0, there is the possibility for multiple status
codes being returned (i.e., no revision selected by a label).
In these cases, should SET-TARGET return a 207 Multi-Status response?
Should a deep SET-TARGET be best effort or all | none?
I believe the answer should be 207 and "best effort".
Anyone feel otherwise?
(a) The description of Merging in protocol 4.8, section 8.1 should point
out that merging is always performed into a workspace.
Done.
(b) After performing a merge, how do you discover all the working
resources that were created by the merge (that represent the client
interaction required to complete the semantic operation)? Clearly if
there were no working resoruces before you stated this would be trivial.
You use the DAV:update-set that is returned by the MERGE request.
In protocl doc. 4.8 section 8.1 the description of Activity includes:
"If an activity selects revisions from multiple history resources, the
revisions selected in each history resource must be on a single line of
descent."
I don't see why the initial condition is required--don't we always want
multiple revisions to be on a single line of descent?
The line immediately preceding the one you quoted handles the case
where there is a single versioned resource. This second sentence is
there to clarify the semantics when there are multiple versioned
resources affected by a single activity.
It is unclear in protocol doc. 4.8 section 9.5 how you go about creating
public/private bindings in a collection.
That section reads:
"A simple strategy for determining what bindings are public is to make
bindings to versioned resources public and make all other bindings
private."
but does not explain how they are made public/private.
I'll try to reword this. The point is that a binding is public if and
only if it is a binding to a versioned resource. So if you create an
unversioned resource in a versioned collection, that is a "private"
member, but if you put that private member under version control, it
becomes a "public" member.
protocol 4.8 section 9.2
(a) This section should include a description of the effect of merging if
the destination workspace target is a working resource or unversioned
resource (presumably, it fails).
The full semantics of merging is defined by the MERGE command (section 13.4).
To keep 9.2 simpler, I thought it better to just give an overview, rather
than give all the details (such as error cases).
(b) The last paragraph reads:
"If the server is capable of automatically performing the MERGE, it MAY
update the content of the working resource and the DAV:predecessor set
itself. An automatic merge is indicated by the absence of a
DAV:merge-set. Before checking in the working resource, the author is
responsible for verifying that the automatic merge is correct."
How would you know which working resources to check if they are indicated
by the absence of a property?
There may be other working resources that were not created by the merge
that also do not have that property.
The working resources the user must manipulate are those in the
DAV:update-set with a non-empty DAV:merge-set. The working resources
the user must verify correctness of the merge are those with more than
one revision in the DAV:predecessor-set.
Why has workspace lost its distinct resource type? (protocol 4.8 section
10.5)
Given that workspaces have interesting behavior and properties that are
not shared by other collections, I think workspaces should have a distinct
type. Call it 'DAV:workspace-collection' if you prefer.
So that a workspace can be handled by a versioning unaware client, that understands
DAV:collection, but would not understand DAV:workspace-collection. For clients
that care whether or not a collection is a workspace, they can check whether it
has one of the protected workspace properties, such as DAV:parent-workspace.
(I just noticed that I forgot to make those properties protected ... I'll fix that).
What is the purpose of the opening paragraph on advanced VERSION (protocol
4.8 Section 12.9)?
It reads:
"If a history resource is specified in the request body, the request-URL
MUST identify a null resource, and a new versioned resource associated
with the specified history resource is created at the request-URL. If no
history resource is specified, a new history resource is allocated for the
new versioned resource at a server-defined location."
This implies that:
(a) VERSION can be used to create new resources with new history, and
(b) VERSION can be used to create new resources that are 'linked into'
existing history.
This seems to be a new use for the VERSION method that may produce a
versioned resource will a null initial revision.
This allows you to either create a new versioned resource with a new
history resource (whose initial revision is a copy of the versionable
resource at the request URL), or create a new versioned resource for
an existing history resource
In case no resource exists at the request URL, and no history resource
is specified, then the dead-properties/body of the initial revision
are empty, but does that cause a problem?
Cheers,
Geoff