Comments on Baseline option (in 12.3)

Here are some (mostly editorial) comments on the Baseline option in
the -12.3 draft.  The only non-editorial comment concerns sub-baselines --
it's not clear to me why they should be in the document at all.

1. Section 10.3.2 (sub-baselines):

"The set of versions captured by the DAV:baseline-collection of a baseline
is logically extended by the versions captured by these other baselines."

(a) What does it mean to be "logically extended"?  I'm guessing you mean
something like set union here.

(b) What is a subbaseline anyway?  A definition in the introductory text of
Section 10 would be nice.

(c) From reading the specification, it's unclear to me what the intended use
is for sub-baselines, and hence why this functionality is in the
specification at all.  If sub-baselines were removed, what capability would
I lose?

(d) When would the server return an error (and what error would it return)
if a sub-baseline did, in fact, contain more than one version resource from
a single version-controlled resource?  Would this happen on a PROPPATCH to
the DAV:subbaseline-set of a checked-out version-controlled configuration?


2. Ambiguity in configuration definition:

In Section 1.4.1, I was a bit thrown off by the definition of
"configuration".  Instead of the first two sentences, I think you meant to
say:

A "configuration" is a set of resources that consists of a root collection,
its internal members, and recursively contains all children of contained
collections.

In particular, the second sentence is bad, since it introduces the notion of
"effectively" invoking an HTTP method, and there currently is no such
concept.  Either a method is invoked, or it isn't.

Finally, the last sentence, while strictly true, is also confusing:

"Note that a collection (which is a single resource) is very different from
a configuration (which is a set of resources)."

Well, yes, a collection is in fact a single resource, but it is used to
*represent* a set of resources (the internal members).  Similarly, a
baseline *represents* the set of resources that comprise a configuration, in
this case using a property to hold the URLs of the members.

It seems to me the differences between the two concepts (configuration and
collection) are:

* a configuration holds a recursive traversal of collection, a collection is
just a single level
* configuration is represented using a baseline (a set represented in a
property), while a collection is represented as a set of bindings
* a collection has specific consistency-maintenance semantics defined in RFC
2518, which a configuration inherits by mirroring the state of a collection
tree

That said, I'm not sure what change to make to the third sentence.  Perhaps
it would be good to add a short paragraph between definitions, decsribing
the relationship of collections and configurations, capturing the points
above.  Or maybe that's overkill.


3. More definitional ambiguity

Next, there is a difference in the definition of configuration given in two
different places in the specification.

In Section 1.4.1, the definition of configuration is:

A "configuration" is a set of resources that consists of a root collection
and all members (not just internal members) of that root collection.

In Section 10, a configuration is defined as:

A "configuration" of a collection consists of the state of that collection
and the state of all members of that collection.

Are these intended to capture the same concept, or is the difference in
wording intentional?  The Sectin 1.4.1 definition implies the set will be
represented using referential containment, while the Section 10 definition
implies the representation will be performed using inclusion containment.
The definition of baseline later clears this up, but perhaps it would be
best to use the same definition of configuration in both places.


4. Difference between baseline and configuration.

So, after looking at the definitions of baseline and configuration, there
seems to be difference -- a baseline represents a configuration, with the
added restriction that a baseline only represents those members of a
configuration that are under version control. For a configuration of a
collection that has versioned and unversioned members, a baseline will be a
subset of the configuration (only the version-controlled resources).

Is this the intent?  If so, perhaps the version-controlled-configuration is
better named a version-controlled-baseline?  If not, then it appears the
definition of configuration needs some tightening.


5. Section 10.2

The heading for Section 10.2 is, "Checked-Out Configuration Properties", and
the section begins with:

"Since a checked-out configuration is a checked-out resource, ..."

This was confusing to me, since I had just got it through my head that a
configuration is, in fact, not a resource at all, but an abstract set. A
baseline *represents* a configuration.  So, does this section mean
"Checked-out Baseline Properties", or "Checked-out Version-Controlled
Configuration Properties"?  I think it means the latter.


6. Section 10.3.1 & Section 10.11 (DAV:baseline-collection)

Since this is a protected and computed property, its state is not guaranteed
to be preserved when a version is made of it, since a version is defined to
be (Section 1.4) "A 'version' is a resource that contains a copy of a
particular state (content and dead properties)".  So, some text is needed to
ensure that DAV:baseline-collection reverts from being a computed property
to a dead property, when the version-controlled configuration is checked-in.
The text in Section 10.11 seems like it is intended to capture this, but
since the property is protected and computed, stating what the value is at
the moment of checkin doesn't provide any guarantees of its future value...


7. Section 10.10 (additional COPY semantics)

This looks like a cut-and-paste of the previous paragraph, changing only the
method.  Is the intent here that this only applies to COPYs of collections?


8. Section 10.6 (definition of BASELINE-CONTROL)

"If no baseline is specified, a new baseline history is created, and the
DAV:checked-in version of the version-controlled configuration will be the
(empty) root baseline of that baseline history."

OK, but what happens if a baseline is specified?  I would guess that the
version history associated with the version-controlled configuration for the
baseline specified in the request body would be used, right?


9. GET, PUT OK?

I'm assuming that, since they're not prohibited, GET and PUT on a
version-controlled configuration are OK, and wouldn't affect the state of
the configuration (since that's represented in a property).

- Jim

Received on Sunday, 11 February 2001 21:38:45 UTC