RE: Comments on Baseline option (in 12.3)

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

Ah. It would be good to add text to this effect.

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

Well, it seems like there is a lot of functionality hiding under the banner
of "logical extension".  There are namespace composition issues:

(a) do the baselines have different namespace trees, or does one baseline
fit into the namespace tree of another baseline?

I.e.:

          B1          B2
        / | \        / | \
     ... ... ...  ... ... ...

The namespaces are disjoint, and hence would need to be combined by creating
a baseline collection that held them both:

                B0
               /  \
              B1  B2
             /|\  /|\
             ...  ...

OR

        B1
        | \         B2
       ... ...     / | \
                 .. ... ...

In this case, no new baseline needs to be created, the composition is:

         B1
       / | \
     B2 ... ...
   / | \
... ... ...


So, the wording here would be something like:

(a) If the baseline namespaces are disjoint, create a new baseline, add this
to the set of subbaselines, and place all subbaselines as children of this
new baseline.

(b) If some of the baselines are children of other baselines, then insert
these baselines into the "appropriate" place in the namespace tree.

But, it seems that it would be difficult to determine where it should appear
in the namespace tree -- which namespace would you use as the normative
namespace for composing baselines?

Or, maybe I'm not understanding how baselines would be logically composed.

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

No, "logical extension" still needs to be defined.

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

Well, you could allow resources to belong to more than one baseline (not
that I'm advocating this necessarily -- you asked ;-), and then you would
have the freedom to create whatever baseline you desired (not
compositionally, just by construction).

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

I didn't like the "all members" bit.  Since a collection's members are just
its level one members, *all* of the members of a collection are just the
level one members.  That's why I explicitly notes that it was the level one
members (the internal members), and then all the level one members of all
child collections, recursively.  We never defined child in RFC 2518, since
we were using the common definition of the term that is used in introductory
data structures texts, and we assumed our reader would have an introduction
to CS data structures (you have to draw the line someplace ;-).

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

Actually, I'd prefer it if the sentence were re-written, or deleted.  I
really didn't understand the intent of this sentence -- my interpretation
was you were trying to express the "recursive tree traversal" aspect, but in
a strange way.

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

No -- all the members of a collection == level 1 members.

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

Ah, this is more precise.

I'll leave the resolution of this up to you, so long as the current text is
replaced.

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

The way configuration is defined, a reasonable assumption about a
version-controlled configuration (just going by the name, and thinking about
what a configuration, under version control might look like) is that it
would include specific version resources, as well as preserved unversioned
resources. Since a configuration can contain both versioned and unversion
resources, a versioned configuration might reasonably also contain both
versioned and unversioned resources.  I'm not advocating that version
controlled configurations should contain unversioned resources -- I'm just
pointing out a reasonable interpretation of the term version-controlled
configuration, and how this diverges from the actual defined meaning of the
term.  Such divergences can lead to confusion while reading the spec.

One possible way of resolving this divergence is to name this a
version-controlled baseline.  Since a baseline only contains versioned
resources, there is no confusion, since there is no expectation that
unversioned resources might be a part of it.

Another way of resolving the divergence is to explicitly note it.

- Jim

Received on Monday, 12 February 2001 13:48:00 UTC