- From: Greg Stein <gstein@lyra.org>
- Date: Thu, 1 Feb 2001 23:55:34 -0800
- To: ietf-dav-versioning@w3.org
On Fri, Feb 02, 2001 at 12:03:04AM -0500, Geoffrey M. Clemm wrote: > From: Greg Stein <gstein@lyra.org> >... > Now, let's throw the Depth: header into the mix. What does it apply to? The > VCR or the Version? It is murky with the Label: header in there. > > It wouldn't make any sense to apply it to the version, because a > version is never a collection, but we should make that clear. Yup. I read up on the Depth: header from RFC 2518, and it seems to indicate that the processing of the Depth: header is method-specific. Meaning we can define the meaning of the (PROPFIND, Depth:) tuple, rather than having to fit into a generic interpretation of Depth:. [ in short: it appears we can make Depth do what we'd like ] >... > DAV:href returns Version Resource URIs. How do we match them up against > the hierarchy defined by the VCRs? > > Well, if your server supports the version history option (which it > should :-), you can do a Depth PROPFIND (without the label header) for the > DAV:version-history property, which would pretty much get you what you need. Hmm. By matching up the version-history properties, I presume? > Depth applies to the Version Resource: > Presumably, you're selecting a collection version. Its children are > version histories, so you're going to get back whacky properties or > nothing at all for the children. > > Actually, collection versions are no longer collections (they just Ah. Right. >... > Okay... let's try to fix the DAV:href thingy by saying you apply the Depth: > header to the VCRs (i.e. apply Depth to the VCR before linking thru to the > version resources) and the DAV:href returns the VCRs' URIs. That makes some > sense, but now we have a problem: how do we get the version resource URI? We > can't use DAV:checked-in because that is a VCR prop. And, oh darn! We just > nuked DAV:version. > > I think returning the VCR URL in the href would be very misleading. > Those aren't the properties of the VCR, they are the properties > of some totally different version resource. Ah. Good point... PROPFIND on a VCR with and without the Label always returning the VCR URL... yah... confusing. >... > *) bring back DAV:version > > I think the fact that we would need to bring it back is an > indication that putting the VCR's URI in the href was a > bad/misleading thing to do. Okay. > Hmm. I'm thinking that the use of a Label: header is rather spurious to the > above issue. It does make it a bit harder to figure out the version resource > URI (without the Label:, you could ask for the VCR's DAV:checked-in; there > isn't an easy equivalent to find the V.R. when you're trying to use a label) > > Note that using the Label header with Depth is basically bogus anyway > when you have versioned collections, because you won't be traversing > the collections that are selected by the label, but rather the > collections that correspond to the current target of the > version-controlled collections. So I wouldn't torque the protocol > around at all for this. Hmm. True... > Bottom line: Labels are for giving a version a human meaningful > name. Baselines are for capturing a set of versions. A server can > implement baselines with labels, but a client can't, and shouldn't > try to. All righty. The basis for my query here was how to access a baseline by (label) name, via a version-controlled configuration. I believe the sequence will be: PROPFIND /some/collection ask for: DAV:version-controlled-configuration PROPFIND /the/version/controlled/configuration Label: the-label-goes-here ask for: DAV:baseline-collection further operations on /the/baseline/collection It would be nice to collapse these via a DAV:expand-property report, but the Label: in the second request nixes that. In any case, while thinking about PROPFIND and Label, I was thinking about the other issues above. (I won't be using a Depth: header, but considering it threw a wrench into the mix) Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Friday, 2 February 2001 02:54:38 UTC