Re: DAV:resourcetype

"Jim Amsden" <jamsden@us.ibm.com> wrote:

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

If we are talking about Java classes and interfaces then I agree.  But
let's focus on webdav resources that simply exhibit well-defined behavior
to methods and have well-defined properties (that may affect that
behavior).

Should a future protocol designer come along and redefine the meaning for
DAV:checked-in to mean something other than it does for DeltaV, then they
will be deliberately introducing an incompatibility and the protocol will
fail.  We have been careful to retain the meaning of RFC2518 methods and
properties and RFC2616 methods in designing DeltaV.

Where such 'subtyping' makes sense, and I predict it is in very few cases,
the well-defined behavior must be the same.  An example is workspace
retaining the meaning of collection.

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

So just how would you capture it in DAV:resourcetype?

Imagine you had a workspace.  If you just set the resource type to be:
  <DAV:resourcetype><DAV:workspace/></DAV:resourcetype>
then existing clients would not treat this as a collection (ok except
WebFolders, incorrectly), and all new clients would have to be programmed
to 'know' that a workspace is-a collection.

Now imagine you set it's DAV:resourcetype as follows:
  <DAV:resourcetype>
    <DAV:workspace/>
    <DAV:collection/>
  </DAV:resourcetype>

This is better since existing clients work fine, and the rule for new
clients is "if it has a <DAV:collection> element then it is a
collection-type resource".

Ok, now we bring the workspace under version control.  By the same argument
you wouldn't use <DAV:version-controlled-workspace-collection/>, but
rather:

  <DAV:resourcetype>
    <DAV:workspace/>
    <DAV:collection/>
    <DAV:version-controlled/>
  </DAV:resourcetype>

and then,

  <DAV:resourcetype>
    <DAV:workspace/>
    <DAV:collection/>
    <DAV:version-controlled/>
    <DAV:version/>
  </DAV:resourcetype>

and so on.  The only workable solution is to make DAV:resourcetype a *set*
of types and/or states.

Now, tell me how is this different to DAV:supported-*-set?

What if someone in the future decides to redefine the meaning of
<DAV:workspace/>.  It would be a breaking change, and it is incumbant upon
them not to do so.

> <jra>
> No. For example a resource and a collection will respond
> to the same methods and have the same properties.

A collection responds to MKCOL whereas a non-collection resource does not
(successfully).

> But
> they respond to GET in very different ways that a client
> is most interested in.
> </jra>

Section 8.4 of RFC2518 states explicitly "The semantics of GET are
unchanged when applied to a collection".  So we are cool.

Tim

Received on Thursday, 21 June 2001 12:34:11 UTC