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

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
will
> > be necessary if they just have one or two more methods or properties
than
> > 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
model
> 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
descriptions.

This is precisely the point I raised in
http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001AprJun/0181.html
        "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
        themselves."

> 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
<DAV:auto-checkout/>
(appears and does not appear, respectively, in
DAV:supported-live-property-set)

> *) is DAV:checkout-set actually unique to a Version resource? Some of
those
>    properties are reflected in VCRs. Which Version Resource properties
*do*
>    get copied to a VCR, and which do not? The ones that don't will
therefore
>    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
http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001AprJun/0115.html

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

Agreed.

> Oh: and Tim argued, "well, for somebody to implement DeltaV, we're going
to
> ask a lot more than simple Set computations." Oh. Great. Just because
some
> 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
also
> 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
acronym-speak:^)

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.


Tim

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