RE: Comments on Baseline option (in 12.3)

   From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]

   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.

Look at the thread labeled "Edgar`s comments to 12.1" (started 1/28/01).
Basically, it's the way that you group together several existing baselines
of different collections into a "system".  Think of it as a way of
composing systems out of sub-systems.

   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.

Yes.  Can you suggest some wording that would make that clearer?

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

Good point!  Will do.  Perhaps that would address your concern 
about section 10.3.2?

   (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?

The ability to form a "composite" baseline out of several smaller
baselines.  Did you have some other way in mind that this would
be accomplished?

   (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?

Good point!  It actually happens when you try to CHECKIN the new
version-controlled configuration, but this is not stated in the
protocol.  I'll add this postcondition to the CHECKIN method.

   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.

Hmm.  I was just using the terminology of 2518.  Although 2518 does
use the term "child", it doesn't define it, but it does define the
terms "member" and "internal member".  What didn't you like about
the existing sentence in 1.4.1?  (Note: I don't care that much if
we switch, but the review from Dan justifiably took us to task for
using undefined terms, so we'd have to define "child" if we used
it, which seems redundant if 2518 already defines the terms
"member" and "internal member").

   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.

Good point.  How about "can be understood as ..." instead?

   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).

What a collection "represents" currently depends on what method
you are applying to it.  If you PROPPATCH it, you are just
PROPPATCH'ing the collection (and definitely not any of its
members).  If you are PROPFIND'ing it, or LOCK'ing it, you
use the Depth header to indicate whether you are operating on
the Collection (Depth:0) or the Configuration (Depth:infinity).

For versioning, what matters is whether you are capturing the
state of a single resource or a set of resources, which is why
the definition of configuration emphasizes that distinction.

   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.

I'd prefer to use the term "captures" or "selects", but what matters
is that you have two very different objects: a collection version and
a collection baseline.  When you introduce the key distinction
between a collection (which contains a set of relationships, called
bindings) and a configuration (which is a set of resources, induced
recursively by the binding relationships), it is much easier to
clearly make the distinction between a version of a collection
and a baseline of a collection.

   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

Isn't "a collection and all its members" a simpler definition?

   * configuration is represented using a baseline (a set represented
   in a property), while a collection is represented as a set of
   bindings

Actually, a configuration is not represented using a baseline,
but rather a baseline captures the state of the version-controlled
members of the configuration.

   * a collection has specific consistency-maintenance semantics
   defined in RFC 2518, which a configuration inherits by mirroring
   the state of a collection tree

Hmm.  I'm not sure that would help many folks.

   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.

I'm happy to iterate on the collection/configuration distinction,
but isn't "a configuration is a collection and all its members"
about as simple and clear as we can make it?

   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?

Good catch!  That was accidental.  I'll change the second definition
to match the first.

   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.

Yes, definitely.

   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?

Yes.

   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.

When you create a "version" of something, you always have to define
what is in that version.  In the case of a simple resource, it is the
content and dead properties (not the live properties).  In the case of
a collection, it is the dead properties and the bindings to the
version histories of the version controlled internal members of that
collection.  In the case of a configuration, it is the DAV:checked-in
versions of the version-controlled members of that configuration.

So it is consistent that only a selected part of the state of
a given resource is captured by a version of that resource.

   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.

Actually, it means both a checked-out version-controlled configuration
and a working configuration.  We should make that explicit, by
providing an explicit definition of "checked-out configuration" and
"working configuration" in the terms section.  (This is just analagous
to how a checked-out resource can be either a checked-out
version-controlled resource, or a working resource).

I better get some sleep ... I'll finish responding to Jim's comments
tomorrow.

Great review Jim!  Thanks!

Cheers,
Geoff

Received on Monday, 12 February 2001 07:21:22 UTC