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

RE: Resource class

From: Tim Ellison <tim@peir.com>
Date: Sat, 2 Jun 2001 23:56:09 +0100
To: <ietf-dav-versioning@w3.org>
> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: 02 June 2001 13:57
> To: ietf-dav-versioning@w3.org
> Subject: 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.

I disagree, the actions to be performed on a resource (the 'menu options')
and the representation of a resource to an application (its 'icon') will be
based on both the supported methods and content.
For example, the 'compiling' action makes sense for a source resource, but
not a binary.  The icon for a version is likely different to that of a
mutable resource.  And so on.
I simply claim that you need both efficiently.

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

MKCOL creates an empty collection, but its DAV:resourcetype still contains
DAV:collection (which is a live property that distinguishes the 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.

<G> Ha! That's a classic!  I didn't see that coming - fantastic!

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

GUI's aside for a moment, clearly there are cases where a different 'type'
may be important in some other respect, and I was speculating that the live
property set of a new type may be a proper superset of an existing type --
and thereby cause a problem.

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

It may be a lot worse than the wrong icon (though I also disagree that
showing the wrong icon is superior).  In this example the 'icon' represents
any number of application level choices based on type that will be screwed

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

My question is how did you come up with 'reptile', 'big teeth', and 'eat
you' as defining properties for the croc?  and how did you know that this
would not collide with the definition of another animal you don't know about

Our choice of live properties to define the type _may_ be equivalent to
having defined a crocodile as 'a large animal with an enigmatic smile', and
you'd open the door expecting your mother-in-law (awh, maybe not such a good
example :-)

Received on Saturday, 2 June 2001 18:56:18 UTC

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