CHECKIN and properties

Section 2.2 and Section 2.3:

Is it a MUST level requirement that a core versioning server support all of
the properties in sections 2.2 and 2.3?  I.e., MUST a version-controlled
resource have all of the Section 2.2 properties defined upon it (well,
really, all that are appropriate for its checked out/checked in state), and
MUST a version resource have all of the Section 2.3 properties defined on
it?  If so, I couldn't find a place that explicitly states this.

Section 2.2.3:

It seems like, most of the time, the server will be setting the value of
DAV:predecessor-set, and except for merges, or adding to the server-computed
value, the client shouldn't try to write to this property.  Is this correct?
If so, it would be nice to capture this in Section 2.2.3, so client writers
have a better expectation about how this property works.

Section 2.2.5:

This seems underspecified to me. There are really two parameters here,
resource is write-locked/unlocked, and autoversion status of when-unlocked,
and when-locked.  We can make a table, and indicate areas that are specified
in this section

                      write-locked                      unlocked
(non-write-locked)

when-unlocked                                      A modification request is
automatically
                          ???                      preceded by a checkout
operation, and
                    (same as unlocked?)            automatically followed by
a checkin.

when-locked       A modification request is
                  automatically preceded by a
                  checkout operation, and an                     ???
                  automatic checkin operation is    (same as above?
(when-unlocked, unlocked))
                  applied when the applied when
                  the write lock is removed.

Also, what happens when the resource is write-locked, and the value of
DAV:auto-version is changed from when-locked to when-unlocked?  Is a version
automatically created upon successful completion of the PROPPATCH (because
there would already be an active CHECKOUT due to the lock, and the
when-locked condition)?

Section 3.2:

CHECKIN takes a version-controlled resource, and turns it into a version
resource which is a copy of its body and dead properties.  Properties that
must exist on a checked-out version-controlled resource are:

DAV:checked-out
DAV:predecessor-set
DAV:precursor-set
DAV:auto-version

Which of these properties should be transferred over to the version resource
created by CHECKIN?  My guess is:

DAV:checked-out: no
DAV:predecessor-set: yes
DAV:precursor-set: yes
DAV:auto-version: no

At the very least, this issue is not currently addressed in the
specification (except for DAV:predecessor-set).  DAV:precursor-set behavior
is described implicitly (by the existence of the property on a version
resource) -- I think it should be made more explicit, in the description of
CHECKIN.

The text describing the (DAV:checked-in) postcondition should explicitly
note that the properties being discussed are on the version-controlled
resource, and not the version resource.

- Jim

Received on Wednesday, 31 January 2001 20:42:51 UTC