Next message: jamsden@us.ibm.com: "Versioning Spec-03 Review - core versioning"
Message-ID: <65B141FB11CCD211825700A0C9D609BC018799D1@chef.lex.rational.com>
From: "Vasta, John" <jvasta@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Tue, 7 Mar 2000 12:46:54 -0500
Subject: Comments on deltav-versioning-03.1
Here are some comments and questions I have after going through the 3.1
draft:
4.1 Auto-versioning is disabled if a Workspace header is supplied. Should it
also be disabled if a Revision-Selector header is used?
5.1 MKRESOURCE: The introduction says that resources can be created and
their
properties initialized in one atomic operation, but the rest of the section
does not explicitly say that a new resource should be destroyed if there was
any error in setting a property. If that is really what is intended, I think
there should be more explicit language to make that clear.
6.1 VERSION: Under Response Marshalling, it says "The following status codes
can appear in the DAV:status element". But the response cannot be
multi-status, so there is no DAV:status element.
6.2 CHECKOUT: Under Response Marshalling, it says "The DAV:response MUST
contain an href containing the DAV:versioned-resource property of the
selected
revision". But the href in the example looks more like a working resource
URL,
which makes more sense to me. Should it be a working resource URL?
6.3 UNCHECKOUT: DAV:status appears in Response Marshalling here too.
6.4 CHECKIN: shouldn't the activity language be removed from this section,
since it only concerns basic versioning?
It sounds like arbitrary properties can be applied to the new revision. What
if there is an error setting a property? Should the checkin be "undone"? It
seems like it could be difficult for some servers to get the resource back
into the checked out state: the new revision must be destroyed, but its
contents must be preserved to become the working resource for the previous
revision, after it is checked out again. And if the resource is a
collection,
it is harder to preserve the contents of the destroyed revision.
Also, if a property operation fails, should the response be multi-status? If
not, the DAV:status language does not apply.
6.4.1 The example checkin-policy is "identical-abort", which no longer seems
to exist.
6.5 LABEL: it isn't clear if multiple label operations can be specified in
one
request. It says "The body of the request contains an XML document with
either
a DAV:add or a DAV:delete member", which sounds singular, but then it says
"The specified labels have been added and deleted from the specified
revision", which sounds plural.
If more than one label operation can be requested, what if one fails? Are
all
other label operations undone? If not, should the response be multi-status,
so
a client can know which operations succeeded and which failed?
If a delete operation is requested for a non-existent label, is that an
error?
6.5.1 The example introduces a DAV:request element, but it is not defined
anywhere. Also, the closing tag should be </D:request>, not </D:response>.
13.1 MERGE: the DAV:status language appears here too.
John Vasta