- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 19 Jun 2001 14:15:03 -0400
- To: ietf-dav-versioning@w3.org
> From: Jim Amsden [mailto:jamsden@us.ibm.com] > 2) the difficulty clients will have in determining the > type of the resource - they have to know the property > semantics instead of relying on the server to hide these > semantics, From: Tim Ellison No, they just need to look and see if the properties and/or methods are supported to correctly type the resource. The latest draft of the spec has an appendix that spells this out. From: Jim Amsden The "semantics" I referred to above is checking for the existence of some set of properties. Just to be precise, the check is for whether the properties are supported, not whether or not they exist (i.e. a resource can support a property even if the property does not currently exist on that resource). What if changes in the protocol necessitate changes in these properties at some time in the future? A change in the protocol must be backward compatible. Just as we cannot say "COPY no longer accepts a Depth header", we will not be able to say "an activity no longer supports a DAV:subactivity property". In addition, any future extensions to the semantics of DAV:subactivity will have to be compatible with its current semantics. This also leads down the slippery slope of using properties with particular values to determine type - that is, confusing state with dynamic type. This is not an issue because we do not check for the existence of a property (much less it having a particular value), but rather just "is that property supported". (But for the record, we're already at the bottom of that slippery slope, because the distinction between state and dynamic type is a fuzzy one at best.) Most modern computer languages in common use do use named types and do not require clients to look inside to figure out what they are. Smalltalk, C++, and Java (at least by default) don't even let clients see in. Encapsulation is a good thing. I think it would be nice if WebDAV could use it too. Encapsulation is preventing you from seeing the implementation. That is exactly what an IETF protocol does ... you can only see and use the public parts (which are the methods and properties defined by the protocol). A public property is as much a part of the type signature as a public method. All we are saying is that we should be using type signature equivalence, rather than type name equivalence, since HTTP does not provide a "subtype declaration" mechanism, but the versioning protocol has defined a type signature exposure mechanism (DAV:supported-method-set and DAV:supported-live-property-set). Cheers, Geoff
Received on Tuesday, 19 June 2001 14:09:56 UTC