- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Sun, 11 Feb 2001 18:37:59 -0800
- To: <ietf-dav-versioning@w3.org>
Here are some (mostly editorial) comments on the Baseline option in the -12.3 draft. The only non-editorial comment concerns sub-baselines -- it's not clear to me why they should be in the document at all. 1. Section 10.3.2 (sub-baselines): "The set of versions captured by the DAV:baseline-collection of a baseline is logically extended by the versions captured by these other baselines." (a) What does it mean to be "logically extended"? I'm guessing you mean something like set union here. (b) What is a subbaseline anyway? A definition in the introductory text of Section 10 would be nice. (c) From reading the specification, it's unclear to me what the intended use is for sub-baselines, and hence why this functionality is in the specification at all. If sub-baselines were removed, what capability would I lose? (d) When would the server return an error (and what error would it return) if a sub-baseline did, in fact, contain more than one version resource from a single version-controlled resource? Would this happen on a PROPPATCH to the DAV:subbaseline-set of a checked-out version-controlled configuration? 2. Ambiguity in configuration definition: In Section 1.4.1, I was a bit thrown off by the definition of "configuration". Instead of the first two sentences, I think you meant to say: A "configuration" is a set of resources that consists of a root collection, its internal members, and recursively contains all children of contained collections. In particular, the second sentence is bad, since it introduces the notion of "effectively" invoking an HTTP method, and there currently is no such concept. Either a method is invoked, or it isn't. Finally, the last sentence, while strictly true, is also confusing: "Note that a collection (which is a single resource) is very different from a configuration (which is a set of resources)." Well, yes, a collection is in fact a single resource, but it is used to *represent* a set of resources (the internal members). Similarly, a baseline *represents* the set of resources that comprise a configuration, in this case using a property to hold the URLs of the members. It seems to me the differences between the two concepts (configuration and collection) are: * a configuration holds a recursive traversal of collection, a collection is just a single level * configuration is represented using a baseline (a set represented in a property), while a collection is represented as a set of bindings * a collection has specific consistency-maintenance semantics defined in RFC 2518, which a configuration inherits by mirroring the state of a collection tree That said, I'm not sure what change to make to the third sentence. Perhaps it would be good to add a short paragraph between definitions, decsribing the relationship of collections and configurations, capturing the points above. Or maybe that's overkill. 3. More definitional ambiguity Next, there is a difference in the definition of configuration given in two different places in the specification. In Section 1.4.1, the definition of configuration is: A "configuration" is a set of resources that consists of a root collection and all members (not just internal members) of that root collection. In Section 10, a configuration is defined as: A "configuration" of a collection consists of the state of that collection and the state of all members of that collection. Are these intended to capture the same concept, or is the difference in wording intentional? The Sectin 1.4.1 definition implies the set will be represented using referential containment, while the Section 10 definition implies the representation will be performed using inclusion containment. The definition of baseline later clears this up, but perhaps it would be best to use the same definition of configuration in both places. 4. Difference between baseline and configuration. So, after looking at the definitions of baseline and configuration, there seems to be difference -- a baseline represents a configuration, with the added restriction that a baseline only represents those members of a configuration that are under version control. For a configuration of a collection that has versioned and unversioned members, a baseline will be a subset of the configuration (only the version-controlled resources). Is this the intent? If so, perhaps the version-controlled-configuration is better named a version-controlled-baseline? If not, then it appears the definition of configuration needs some tightening. 5. Section 10.2 The heading for Section 10.2 is, "Checked-Out Configuration Properties", and the section begins with: "Since a checked-out configuration is a checked-out resource, ..." This was confusing to me, since I had just got it through my head that a configuration is, in fact, not a resource at all, but an abstract set. A baseline *represents* a configuration. So, does this section mean "Checked-out Baseline Properties", or "Checked-out Version-Controlled Configuration Properties"? I think it means the latter. 6. Section 10.3.1 & Section 10.11 (DAV:baseline-collection) Since this is a protected and computed property, its state is not guaranteed to be preserved when a version is made of it, since a version is defined to be (Section 1.4) "A 'version' is a resource that contains a copy of a particular state (content and dead properties)". So, some text is needed to ensure that DAV:baseline-collection reverts from being a computed property to a dead property, when the version-controlled configuration is checked-in. The text in Section 10.11 seems like it is intended to capture this, but since the property is protected and computed, stating what the value is at the moment of checkin doesn't provide any guarantees of its future value... 7. Section 10.10 (additional COPY semantics) This looks like a cut-and-paste of the previous paragraph, changing only the method. Is the intent here that this only applies to COPYs of collections? 8. Section 10.6 (definition of BASELINE-CONTROL) "If no baseline is specified, a new baseline history is created, and the DAV:checked-in version of the version-controlled configuration will be the (empty) root baseline of that baseline history." OK, but what happens if a baseline is specified? I would guess that the version history associated with the version-controlled configuration for the baseline specified in the request body would be used, right? 9. GET, PUT OK? I'm assuming that, since they're not prohibited, GET and PUT on a version-controlled configuration are OK, and wouldn't affect the state of the configuration (since that's represented in a property). - Jim
Received on Sunday, 11 February 2001 21:38:45 UTC