- 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