- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 13 Dec 2001 23:56:04 -0500
- To: ietf-dav-versioning@w3.org
From: Alison Macmillan [mailto:alison.macmillan@oracle.com]
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 of its
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.
Correct.
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.
Correct.
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.
Correct.
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?
If a server supports version-controlled collections, and if
a version-controlled collection gave a name to a
version history, and that version history is the root of a
subbaseline, then that subbaseline is restored at that location.
But otherwise, no, the protocol does not require a server to
preserve anything about the relative locations of subbaselines.
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.
This is automatically captured by version-controlled collections, but
it certainly would be reasonable (although not required) for a server
to support this even if it does not support version-controlled
collections (clients that expect version-controlled collections will
expect this kind of behavior).
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.
It is not required behavior unless the server supports version-controlled
collections, but it is certainly legal for a server to do so.
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.
Yes.
Cheers,
Geoff
Received on Thursday, 13 December 2001 23:56:39 UTC