- From: Alison Macmillan <alison.macmillan@oracle.com>
- Date: Thu, 13 Dec 2001 18:02:53 +0000
- 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 UTC