RE: Removing the DAV:activity and DAV:version-history and DAV:bas eline resource type values

"Clemm, Geoff" <gclemm@rational.com> wrote:
>    From: Tim Ellison [mailto:tim@peir.com]
>
>    It would appear that there are two camps represented on the list.
>
>    Those that want more info in DAV:resourcetype, even if that means
>    duplicating information that can be deduced by
>    DAV:supported-live-properties et al.
>
>    Those that want the opposite, i.e. downplay DAV:resourcetype and
>    rely on the capabilities of a resource to determine it's 'type'.
>
>    Pistols at dawn?  A democratic vote?  Reasoned debate?
>
> I'll go for what's behind door number three (reasoned debate).
>
> As tempting as it is to continue the alligator and mother-in-law
> analogies (:-), it's probably more productive to focus on a concrete
> benefit these new DAV:resourcetype values provide to a client.

(Sorry about that -- but I can't talk about bytes on the wire for too long
without getting a bit silly.)

> So to start off, let's look at the only DAV:resourcetype value defined
> by RFC-2518: DAV:collection.  The utility of this resourcetype value
> is clear: if you have done a PROPFIND's with Depth:1, this tells you
> whether to put a "+" next to a member resource, telling the
> user that they can ask for nested members of that member.

Agreed.  Or, indeed a PROPFIND depth zero, whatever.

> As an aside, what RFC-2518 *should* have done is provide some live
> property such as DAV:internal-member-count.  This would have given
> the client the same information (i.e. this resource can have internal
> members), but also given it something useful (like how many members
> it has).  But this thread is not to correct the mistakes of RFC-2518
> (but that doesn't mean we shouldn't learn from those mistakes :-).

Ok, but I've also never seen anybody confused by the DAV:collection
'marker' or its purpose either, so we can assume that it is a reasonable
thing to do.

> The floor is now open for proposed additions to DAV:resourcetype,

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.

So, for example, a resource may have a DAV:resourcetype as follows:
    <DAV:resourcetype>
        <DAV:collection/>
        <DAV:version/>
    </DAV:resourcetype>
and another may have:
    <DAV:resourcetype>
        <DAV:version-controlled-resource/>
    </DAV:resourcetype>

I'm guessing that I don't need to explain what the additional annotations
are conveying(?) and that is my point.  Isn't it more intuative to see
<DAV:version/> in the resource type rather than looking for the
DAV:version-name property and deducing that therefore the resource is a
version?

> and a specific reason for that addition

It is going to make the adoption of deltav easier because people will
understand it better.
It will also remove the possibility of ambiguity being inadvertantly
introduced by some later addition to the specification (though due
diligence would dictate that the future designers avoid such pitfalls).

> (i.e. what specifically
> can clients do with that new value that they couldn't already do
> without it).

I agree that giving resource type a new value will not give clients any
further capabilities.  I never intended to portray this as a failing of the
specification, and it certainly should not hold up its progress through the
process.  It is a matter of style, and I think that is why there is a
protracted debate about it.  The problem has already been solved, and I
have had the opportunity to express my viewpoint.  I have no objection if
the authors 'pull-rank' and proceed.

Tim

Received on Monday, 4 June 2001 12:26:27 UTC