RE: [ietf-dav-versioning] <none>

   > 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