- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sun, 3 Jun 2001 00:05:07 -0400
- To: ietf-dav-versioning@w3.org
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