RE: Resource class

   From: Tim Ellison [mailto:tim@peir.com]

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

This is only true for languages that do not provide for "namespaces"
for their property names (which therefore leads to unexpected
property name collisions).  But in WebDAV, we use XML namespaces to
prevent unintended property name collisions.  This means that the
method and live property of a resource will be a proper superset of
those of another resource only if it is a "subtype" of that other
resource.

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

I'd need some specific (and compelling :-) examples.  Someone that is
extending the protocol by re-using existing properties needs to be
aware of the semantics of those properties, and not modify them.  This
then allows any client that knows about those properties to interoperate
effectively against any resource that displays that subset.

Cheers,
Geoff

Received on Sunday, 3 June 2001 00:05:47 UTC