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


From: Jim Amsden <jamsden@us.ibm.com>
Date: Thu, 21 Jun 2001 09:31:18 -0400
To: ietf-dav-versioning@w3.org
Message-ID: <OF9D791460.1E8330D2-ON85256A72.0048E936@raleigh.ibm.com>
See <jar> tags below. My mailer doesn't put in the >'s. Sorry.

> This works *except* for (sub)types that don't
> introduce additional properties.

The argument goes, if the subtype does not introduce additional properties
(or methods) then it is not a subtype at all since it is indistinguishable
from its supertype.
Absoultely not! A subtype may override methods in such a way that very 
different behavior occurs even though the signatures are the same. That's 
why interfaces aren't enough. You need the subtype name to make the 
distinction unless you're willing to invoke the method and use the result 
to determine the type. This is often too late though.

Furthermore, since a subtype supports all the properties and methods of 
supertype that subtype can be correctly treat as an instance of the
supertype.  This provides the future compatibility with specifications 
introduce new subtypes.  However, if types are simply named then there is
no reason to deduce that a DAV:workspace can be treat as a DAV:collection.
Subtypes are interface compatible with their supertypes, but that doesn't 
mean they are the same object. Yes a client can invoke the same methods 
and access the same properties, but the meaning might (should) be 
different. Its this information we capture in the DAV:resourcetype.

> Its a little more
> inconvenient, but perhaps won't be that different if
> we really solved the type hierarchy problem.

Does DAV:supported-live-property-set and DAV:supported-method-set do this
for you?
No. For example a resource and a collection will respond to the same 
methods and have the same properties. But they respond to GET in very 
different ways that a client is most interested in.

> The end
> result is that DAV:resourcetype is pretty useless.

Agreed.  Geoff suggested previously that RFC2518 would have been better to
define a distinguishing property for a collection resource.
But this only moves the problem to the next time behavior changes. Then, 
as Alan pointed out, we're forced to add distinguishing properties that 
look a lot like DAV:resourcetype.

> Geoff, do we still have a potential problem with the
> introspection approach in cases where new types don't
> introduce new properties?

See above.

> Unfortunately type depends
> on more than signature, it also depends on behavior,
> and this isn't captured in the supported properties
> in all cases.

See DAV:supported-method-set
This isn't enough. It's not just the supported methods, but what those 
methods do.

> Collections in DAV are an example.
> They can be considered a kind of resource that doesn't
> introduce new properties, but does change method behavior.
> Clients will of course have to be able to distinguish
> them in order for users to understand the results of
> their requests.

Received on Thursday, 21 June 2001 09:31:25 UTC

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