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
up
         into a set of smaller configurations that form the logical
         "components" of that configuration.  In order to capture the
fact
         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
configuration
         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
its
         components (e.g. configuration /sys/y/z can have a component
         /sys/y), or neither (e.g. configuration /sys/x can have a
component
         /comp/bar).


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

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

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.

Thanks,
Alison.
--
 -------------------------------------------------------------
 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT