W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

baselines & namespaces

From: Alison Macmillan <alison.macmillan@oracle.com>
Date: Thu, 13 Dec 2001 18:02:53 +0000
Message-ID: <3C18ED4D.22F29EE@oracle.com>
To: ietf-dav-versioning@w3.org
I've got a question to do with preserving the location in a namespace of
the root of a baseline.

Section 12 has the following discussion of subbaselines and components:

         As a configuration gets large, it is often useful to break it
         into a set of smaller configurations that form the logical
         "components" of that configuration.  In order to capture the
         that a baseline of a configuration is logically extended by a
         component configuration baseline, the component configuration
         baseline is captured as a "subbaseline" of the baseline.

         The root collection of a configuration is unconstrained with
         respect to its relationship to the root collection of any ofits

         components.  In particular, the root collection of a
         can have a member that is the root collection of one of its
         components (e.g. configuration /sys/x can have a component
         /sys/x/foo), can be a member of the root collection of one of
         components (e.g. configuration /sys/y/z can have a component
         /sys/y), or neither (e.g. configuration /sys/x can have a

My understanding of the protocol is that a baseline does not record
where in a namespace the root of the baseline should be located. The
baseline records the versions and relative names of members of the
baseline, i.e. it preserves a namespace where the baseline-collection is
the root of the namespace.

I also thought that while a baseline can have subbaselines, this set of
baselines does not define where in a namespace each baseline should be

Given the DAV:baseline-controlled-collection-set property of a
workspace, I had assumed that the workspace acted as a namespace that
preserved the relative name of the root of each baseline.

So, for example, to populate a new workspace from a workspace that
publishes a set of baselines, the client would issue MKCOL and
BASELINE_CONTROL requests to populate the new workspace with baselines
chosen from, & as named in, the publishing workspace.

Have I understood this right? Or is there something in the structure of
a baseline itself, that preserves the relative name of another baseline?

I wondered if it was expected that a baseline implementation should
record a "baseline-binding", where a baseline-binding is a (name,
baseline-history) pair. The baseline-collection, or any collection which
is a member of the baseline-collection, would retain a baseline-binding
if at the time the baseline was created the collection had an internal
member which was baseline-controlled.

Then, on BASELINE-CONTROL of a collection in the new workspace from a
baseline, the server could restore a subbaseline  if the baseline
contains a baseline-binding for the baseline-history of the subbaseline.
The BASELINE-CONTROL method does not include a postcondition for
subbaselines, so I'm not sure if this would be compliant behaviour or

Finally, the cases where a subbaseline is located outside of the
namespace of the baseline (examples /sys/y/z +/sys/y and /sys/x +
/comp/bar from above), would seem to rely on baseline-bindings being
preserved in some other baseline (if the intention is to automate this),
and being present in the target namespace of the operation.

 The statements and opinions expressed here are my own
 and do not necessarily represent those of Oracle Corporation.
Received on Thursday, 13 December 2001 13:04:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC