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

Re: possible new property?

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 16 Feb 2001 13:16:49 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569F5.0048F582.00@d06mta07.portsmouth.uk.ibm.com>

> For VCRs that are under baseline control, I propose that
> we add a new property that specifies their relative path
> to the "root" of the baseline, where the root is defined
> by the baseline's DAV:baseline-collection property.

I assume that you are referring to the checked-in VCRs in the

> [ hmm. just noticed something: that property assumes the
> baseline is not disjoint. fixing that is "out of scope"
> of this message :-) ]

I'll watch for the other message, I don't know what you mean.

> Without the property mentioned above, it would be very
> difficult to figure out where to go in a baseline to
> find the matching resource.

What does 'where to go in a baseline' mean?
Can I assume you mean the DAV:baseline-collection?

> Specifically, the algorithm would be something like:
> 1) for a resource "R", get the DAV:version-controlled-
> configuration property from the resource (if a collection)
> or its parent
> 2) get the DAV:checked-in property of the VCC to get
> the baseline
> 3) get the DAV:baseline-collection property from the
> baseline

Ok, I'm with you so far.

> 4) get the DAV:version-history property of the resource
> at the root of the baseline-collection

> 5) starting at R, set "current" to R, then:
>    -) fetch the DAV:version-history of "current"
>    -) if it matches the VH from the baseline-collection,
> then exit loop
>    -) set "current" to parent of "current". loop.

If I understand this correctly, you mean find the relative path from the
baseline-controlled collection to R.

The baseline-collection may not in general have a version-history since it
may not be a checked-in version-controlled collection (i.e., it may be
baselined and not versioned).

Why not use the relative path you walked in step (1) above when finding the
DAV:version-controlled-configuration property in step (6), and discard step
(5) altogether?

> 6) use the relative path between "current" and R to
> move downwards within the baseline-collection

However, I think you'd have to do a top down search through the
DAV:baseline-collection for the matching history resource as R because the
namespace may have been 'messed up' and the VCR corresponding to R could be
in a different spot (heuristically you could look along the same path as
the baseline controled collection...)

> Steps 4 and 5 just disappear if the baseline-relative-path
> property is present on the VCR.

Agreed.  However, the same VCR could be baselined in numerous baselines and
the relative paths would not be the same.

> (note that steps 1, 2, and 3 are a single expand-property
> report; step 6 is just URL construction -- there is no
> server request)


> With the property, we have a single REPORT. (to fetch
> the relative path, and to expand thru the VCC and the
> baseline to the baseline-collection)
> Without the property, we have a REPORT plus N additional
> requests.


> Note that we can also use the relative path to (hopefully)
> access other baselines. Presuming the "current" baseline
> defined by the VCC isn't too far different from the target
> baseline, the path will still apply.

Hmm, I'd be reluctant to introduce a property whose value has a sense of

> Any thoughts?
> Cheers,
> -g

Received on Friday, 16 February 2001 08:18:28 UTC

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