RE: Removing the DAV:activity and DAV:version-history and DAV:baselin e resource type values

"Jim Amsden" <jamsden@us.ibm.com> wrote:
> This is really a sticky one. On the one hand, we have
> introduced many new resource types in DeltaV, but only
> defined DAV:resourcetype for some of them,

Without wanting to open the can of worms again, I have argued previously
that a resource's _state_ is equally important to it _type_; and that there
is no universal definition of state and type.

> and we know this causes problems for some servers.

I'd be interested to know what problems these are.

> If we don't use
> DAV:resourcetype, then we don't introduce compatibility
> problems with DAV level 1 or 2, and DeltaV servers can
> interoperate somewhat with DAV clients (one of our
> primary requirements). We're not really just trying to
> support existing servers with bugs, but make sure we
> maintain interoperability.

Agreed.

> Just providing new resource
> types isn't enough. We need to provide a backward
> compatible type hierarchy scheme so down-level clients
> can see for example, a baseline as a DAV:collection.

A baseline is not a collection, but if you had said "so that clients can
see workspaces as a DAV:collection" then I would agree with you <g>

> We
> could do this, but it would be another rat-hole, and
> then there's the problem with existing servers that
> might not parse the extended XML properly. These are
> of course things we'd like to avoid if we can.

I don't think this is a rat-hole.  The only case from RFC2518 that we have
to deal with is DAV:collection.  The DeltaV spec. states which resources
are compatible with DAV:collection semantics.

> So we're left with removing our DAV:resourcetypes, and
> requiring clients to introspect supported properties on
> a resource to figure out the type based on a table in
> the spec.

I'm not sure why you call it "introspection".  Clients must consider a set
of values reported by two required properties
(DAV:supported-live-property-set and DAV:supported-method-set).

I argue that the alternative is that clients must consider a set of values
reported by a different rquired property (DAV:resourcetype) if we choose to
extend that property with state and type information.

The third alternative is to require clients to deduce type from
DAV:resourcetype and state from DAV:supported-live-property-set and
DAV:supported-method-set, but there seems little advantage to that
approach.

> 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.

Furthermore, since a subtype supports all the properties and methods of its
supertype that subtype can be correctly treat as an instance of the
supertype.  This provides the future compatibility with specifications that
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.

> 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?

> 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.

> 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

> 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.

Agreed.

Regards,
Tim

Received on Thursday, 21 June 2001 05:51:52 UTC