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

RE: Removing the DAV:activity and DAV:version-history and DAV:bas eline resource type values

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 21 Jun 2001 14:59:41 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E24BD@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Lisa Dusseault [mailto:lisa@xythos.com]

   I second what Jim's saying.  Furthermore, I'd point out that server
   implementations differ.  Servers may not implement all live
   properties or methods that a client expects.  Some servers may add
   new, custom live properties.  Does that change the type and make
   the client unable to confidently deal with the resource?

So, how does a client interoperate with such a server?  Either the
server lies, and says it supports a given "resourcetype" when it only
supports a subset of the methods and properties defined for that
"resourcetype", or it makes up some new server-specific resourcetype
for that resource.  In the former case, an interoperable client
assumes that the server is telling the truth, only to find that
certain unimplemented methods fail and certain live properties are
absent or have unexpected values.  In the latter case, an
interoperable client (that hasn't been coded specifically against that
server) says "I don't know what that resource is", and doesn't try to
access any methods or properties from that resource (since it doesn't
recognize the value in the DAV:resourcetype property).

Now suppose instead the client uses the values in
DAV:supported-live-property-set and DAV:supported-method-set to
determine if a given resource provides a set of services that it
will use (note that this might be a subset of the defined
properties and methods for a "resourcetype", since it might not use
all the defined properties and methods).  In this case, the client
works properly against a server that either subsets or extends the
supported methods and properties.

So I applaud your argument, but point out that it leads
to the opposite conclusion from the one you reached.

   So ask yourself if removing resource types in DeltaV improves simplicity.
   It does not.

The simplicity argument is minor to irrelevant.  The argument against
DAV:resourcetype is that it is at best redundant, and at worst,
as your scenario illustrates, it is even harmful since it decreases
the likelihood that a client will interoperate with a wide range of

Received on Thursday, 21 June 2001 14:54:05 UTC

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