RE: Resource class

Resent (again) something fishy going on...
-----------------------------------
> "Clemm, Geoff" <gclemm@rational.com> wrote:
>    From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
>
>    The issue of determining a versioning resource's classification
>    based on the absence (or otherwise) of properties has been raised
>    before on the list.  Recently however, (in other contexts) people
>    have shifted in favour of extensions to <DAV:resourcetype> to
>    convey more 'type' information.
>
> Not me ... I think you should just look in the
> DAV:supported-method-set and DAV:supported-live-property-set for the
> methods or properties that you care about.  If it supports the methods
> and properties you care about, who cares what's in the "resourcetype"
> field (:-).  But then again, if you want to add a bunch of redundant
> information to the resourcetype field, I guess I don't really care all
> that much (although it does violate the Goland rule of "you are done
> when there is nothing left to cut out" :-).

The '(in other contexts)' that I was referring to was the ACL list.  I
understood that the proposal was to extend <DAV:resourcetype> there with
principal and other distinguishers.  I now wonder why there would be two
different mechanisms adopted to solve the same problem.  What am I missing?

Naturally, I'm not in favour of introducing 'a bunch of redundant
information' anywhere in the spec.  I agree that the
<DAV:supported-live-property-set> has all the information needed.

<<snip>>

> Note that whether or not a resource is checked-in or checked-out
> is normally considered part of its "state" rather than part of
> its "type" (which just illustrates the vague boundary between
> "state" and "type" :-).  If you wanted to know whether or not
> a resource was checked-in or checked-out, then you would have
> to PROPFIND for checked-in and checked-out.

I agree that the distinction is vague, which is why I said
'classification'.  When making high-level UI decisions (menu options
greyed-out, choice of icons, etc.) the information required is usually
'type' _and_ 'state'.  Providing an efficient means of getting the full
classification will be important for responsive UIs.

Since <DAV:checked-in> and <DAV:checked-out> will appear in the
<DAV:supported-live-properties> set I believe that it will be sufficient to
PROPFIND on <DAV:supported-live-properties> and <DAV:resourcetype> (for
<DAV:collection/> or a MIME-type etc.) to get an accurate classification.

>>REQUEST
     PROPFIND /foo HTTP/1.1
     Host: bar.com
     Content-Type: text/xml; charset="utf-8"
     Content-Length: xxx

     <?xml version="1.0" encoding="utf-8" ?>
     <D:propfind xmlns:D="DAV:">
         <D:prop>
             <D:supported-live-property-set/>
             <D:resourcetype/>
         </D:prop>
     </D:propfind>

<<snip>>

>    (ii) It would seem that activities should have a <DAV:resourcetype>
>    of <DAV:activity>, but I didn't see that in the -15 spec.
>
> It appears in the postcondition of MKACTIVITY, but I'm happy to
> mention it in section 13.1 as well.

I think that would be more consistent with other declarations of
resourcetype.

<<snip>>

> Or (as I'm sure you can predict I will say ... :-) how about just
> using DAV:supported-live-property-set?

Ok, I get the point<g>

However...
It feels strange (in a woolly, hand-waving way) to characterise a resource
based soley upon its observed/stated behavior -- especially given the
existance of a <DAV:resourcetype> property that is being used intuatively
in some cases (e.g. an activity), and not in others (e.g. a
version-controlled configuration).

The danger that I see is that clients must base their characterisations of
resources on the existance of specific live properties, and that future
extensions to DeltaV will have to bear this in mind when defining new
resource 'types'.  Spec writers will have to deliberately *undefine* a
property just so that clients don't mistake them for the DeltaV types.
For example, if I had an idea for a resource that was not a Baseline, but
had a legitimate use for the <DAV:baseline-collection> property, all legacy
(to-be:-) clients would spot the <DAV:baseline-collection> property and
incorrectly assume it was a Baseline.

How much more verbose English would be if we had to describe the
characteristics of a crocodile and an alligator in order to distingush them
rather than rely on their names.

Tim

Received on Monday, 14 May 2001 16:38:57 UTC