W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: further baseline-related comments on deltav-10.1

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 19 Oct 2000 16:35:07 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <8025697D.005594AF.00@d06mta07.portsmouth.uk.ibm.com>

I agree with all of Geoff's points, except for the current position on the
baselines and their namespace info.

One the one hand, there is agreement that a baseline needs to capture
namespace info.

> This needs to be changed to say:
> "the state of a baseline is limited to be a set
> of versions and their relative names in the collection".

On the other hand, revealing this namespace information is claimed to be an
unreasonable burden.

>> Approach (B) feels more general, and allows baselines
>> to be offered by a server that does not offer versioned
>> collections (e.g., something like CVS). Moreover, the
>> additional information captured in the baseline should
>> not represent a significant burden for servers planning
>> to offer both baseline and versioned collections.

> This information could be expensive to compute for certain
> implementations.  I believe this places an unreasonable
> burden on baseline implementors.  They should just be
> required to implement the "restore" and "merge" operations.

I find it hard to imagine an implementation that supports baselines that
would not be able to cough up namespace information as readily as it could
the version set. But perhaps someone has a counterexample.

I agree that the minimal requirements are "restore" and "merge".  (A
hard-nosed person would observe that the DAV:version-set property is not
required to meet either of these

But it feels like the DAV:version-set property is currently a half-measure;
the information is of little use without the corresponding namespace info,
which we know every implementation has in some form.

The advantage of revealing the namespace info in addition to the version
selection is that it makes it possible for a client to query a baseline and
reconstruct the resource
tree---client-side---without having to create any new objects on the
server. Currently, the only way to reconstruct the resource tree for
browsing purposes requires read-write access. I believe there is benefit in
enabling clients who do not have the permission to create new workspaces to
browse the contents of a existing baselines. The can only do this if the
namespace info is divulged in addition to the version set.
Received on Thursday, 19 October 2000 11:42:32 UTC

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