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

Re: Re (2): Removing the DAV:activity and DAV:version-history and DAV:baseline resource type values

From: <Tim_Ellison@uk.ibm.com>
Date: Wed, 6 Jun 2001 10:16:33 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <80256A63.0032EB28.00@d06mta07.portsmouth.uk.ibm.com>

Greg Stein <gstein@lyra.org> wrote:
> On Tue, Jun 05, 2001 at 05:29:08PM -0400, Edgar@edgarschwarz.de wrote:
> >...
> > Then you always will have discussions about whether new resource types
> > be necessary if they just have one or two more methods or properties
> > another one.
> The resources in the spec are not defined by the set of methods or
> properties. They are defined by *human* concepts. We have identified a
> which incorporates Version Controlled Resources, Baselines, Activities,
> Workspaces, Working Resources, Version Resource, etc.
> Note that I used labels to define those things. I did *not* use
> {DAV:checked-in}, {DAV:baseline-collection}, {DAV:activity-version-set},
> {DAV:workspace-checkout-set}, {???}, {DAV:checkout-set} as the

This is precisely the point I raised in
        "One suggestion is to annotate DAV:resourcetype with
        those types and categorizations adopted by the Delta-V
        specification (version, working resource, baseline, etc.)
        Those types were obviously considered important when
        writing the specification to aid in its understanding,
        so it seems reasonable to reflect them in the resources

> Some further points:
> *) howthehell do I describe a Working Resource? I can't see that it has a
>    unique property.

(You're going to like this :-)

A working resource has <DAV:checked-out/> and does not have
(appears and does not appear, respectively, in

> *) is DAV:checkout-set actually unique to a Version resource? Some of
>    properties are reflected in VCRs. Which Version Resource properties
>    get copied to a VCR, and which do not? The ones that don't will
>    signal whether a resource is a Version resource or not.

A version is identified by its support for the <DAV:version-name> property.

For the full list of defining properties, plus Geoff's corrections, see

> Sorry. But the human is what we are writing this spec for. And we attach
> labels to these things. Not a set.


> Oh: and Tim argued, "well, for somebody to implement DeltaV, we're going
> ask a lot more than simple Set computations." Oh. Great. Just because
> part is difficult, that means we can make *everything* difficult? That's
> bogus.
> "Hey, John. You can do DeltaV if you can jump over this 6 foot bar. Oh.
> Wait. The DeltaV designers said that if you can do that, then you can
> jump over this 10 foot bar. Cool. Go, man! Jump!"
> pthtpth. Non-starter.

(I don't know what 'pthtpth' means, but you probably just swore at me in

Flame on.

Come on Greg -- you can't be serious.
(1) Performing set intersection is absolutely trivial.  It requires WAY
more intelect to figure out how to implement merge functionality, XML
parsing, PROPPATCH atomicity.
(2) If we _do_ go for extending DAV:resourcetype the likely outcome is
something like a *Set* of orthogonal characteristics, such as
<version-controlled-resource>, <collection>, <checked-in> -- guess what,
you'll have to do that "difficult" Set thing again anyway.
(3) Just because I said that there is more to delta-v than these simple
operations doesn't mean that I'm suggesting we make everything difficult.
That doesn't follow at all.  Clients and servers are *already* doing these
Set operations for each PROPPATCH, PROPFIND and other methods.
Give people some credit.

Received on Wednesday, 6 June 2001 05:18:15 UTC

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