RE: Resource class

   From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]

   ....  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.

Deciding what menu options to put up should be based on
DAV:supported-method-set.  The "icon" that is chosen should be based
on the "content" of the resource.  For the versioning metadata
resources, this can be inferred from the
DAV:supported-live-property-set.  The only time you need
DAV:resourcetype is when there are not any special live properties for
the resource (for example, there is no live property that lets you
distinguish an empty collection from a non-collection resource).

   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.

   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).

Good point.  We are currently unnecessarily setting DAV:resourcetype
for a few resources (e.g. activities), when this information is
already available in DAV:supported-live-property-set.

I propose that we delete this redundant and inconsistent use of
DAV:resourcetype from the versioning protocol.

If consensus is ever reached at the general
WebDAV level that we should extend DAV:resourcetype with sets of
tokens, we can then add this information in a consistent fashion
(i.e. consistent wrt whatever criteria is decided for what goes
into DAV:resourcetype).

   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'.

If a new resource type has exactly the same
DAV:supported-live-property-set as an existing resource type, I
believe it is reasonable and correct for the GUI to show the same icon
for both resources.

   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.

A client that cared about this would look for an exact match with
the set of DAV:supported-live-property-set for a baseline.  And if
it didn't have an exact match, I suggest that displaying the
baseline icon (or whatever icon has the best matching property
set) is significantly superior to displaying the "unknown resource
type" icon.

   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.

Suppose I had an "X-ray vision WebDAV" application on my palm pilot
that I pointed at a closed door in front of me.  If that application
was written before the "alligator" resource was defined, I'd much
rather have the "reptile with big teeth that will eat you" icon pop up
on my palm pilot, than the "unknown resource type" icon.  (:-).

Cheers,
Geoff

Received on Saturday, 2 June 2001 08:57:52 UTC