- From: <Tim_Ellison@uk.ibm.com>
- Date: Wed, 14 Mar 2001 11:24:31 +0000
- To: ietf-dav-versioning@w3.org
Greg wrote: > A while back, Tim and I were discussing where DAV:vcc > property appears within "normal" collections. Tim said > "only on the root" and I said "on all collections under > the root". I believe we need to figure out the right > answer here. > > Tim says it appears only on the resource that BASELINE- > CONTROL was applied to (or implicitly applied by the > server). I'm not sure of the basis or explanation for > this since I don't agree :-) ... Tim will speak up. There are a couple of reasons: (1) If you believe that nested baselines makes sense then the DAV:version-controlled-configuration (DAV:vcc) property must be either only on the root of the baseline controlled collection, or the property must support multiple values to represent the nesting. (Incidently, the property definition in draft-13 12.4.1 refers to applying the property to '...a collection when it is created, or [brought under BASELINE-CONTROL]...'. If the property is applied to multiple collections this should be made explicit.) (2) Furthermore, if all resources in a configuration had a DAV:vcc property it would be very confusing for the client to know the scope of a baseline. A client may check out/in a vcc and get a new version of a baseline with a far wider scope than the configuration rooted at the source of the DAV:vcc. For example, getting the DAV:vcc from /a/b/c/d/ and creating a new version of the vcc would capture a baseline that includes everything below /a/b/c/d/; however, the baseline may have been created for /a/ and the operation would have actually captured a larger scope. The only way to figure out the true scope would be to walk up the 'normal' namespace hierarchy to find the root. > I believe it should be on the root and everything below > it. All of those collections *are* under baseline control. I agree that the collections are under baseline control, but it is the root of the configuration that defines the baseline scope. If a child collection is MOVEd out of the baseline controlled configuration it should not take it's DAV:version-controlled-configuration property with it. The root's the guy!<g> > If the baseline changes, they will also change. Not sure what you mean here -- I'd state it the other way around, if they change that implies a change to the baseline when the vcc is checked out/in. > A change > in the baseline ripples down through the entire URL > namespace, so those collection truly are controlled by > the baseline (well, the version-controlled configuration). Oh, you are probably referring to the 'destructive replace' postcondition of UPDATE? > In Tim's scheme, to determine whether something is > controlled, you must issue a bunch of PROPFINDs, walking > up the hierarchy, to determine whether something is > controlled. In mine, a single PROPFIND will do it. If this is objectionable, a trivial new REPORT would fix it. > Originally, I had a problem with determine where the > VCR appeared within a baseline-collection (BC) (i.e. a > VCR's relative path from the root of the baseline). Tim's > scheme can determine this by how far up you walk, and > applying that relative path against the BC. I resolved > mine as a DAV:locate-history report on the BC. I now believe that the DAV:locate-history is preferrable, due to the 'messed-up namespace' problem we discussed at the time. I see your approach, and I am not fundamentally opposed to it; however, I think we should agree on just one <g> and there are therefore some clarity issues that should be addressed in the spec. Tim
Received on Wednesday, 14 March 2001 06:34:31 UTC