W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: DAV:version-controlled-configuration

From: <Tim_Ellison@uk.ibm.com>
Date: Wed, 14 Mar 2001 11:24:31 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <80256A0F.003ED26C.00@d06mta07.portsmouth.uk.ibm.com>

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:

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.)

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

> 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

> 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.

Received on Wednesday, 14 March 2001 06:34:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC