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

It's not just that down-level clients are looking for DAV:collection, but 
unfortunately how. If I remember right, someone tried extending 
DAV:resourcetype and found that it broke MS web folders. I think that's 
why we all backed away from this solution.

What I meant was that clients that only know about DAV:collection probably 
can't make much use of activities, workspaces, and baselines anyway, 
except by treating them as simply resources. The problem is that some new 
resources might be a kind of collection where down-level clients could do 
something with them. I don't think DAV:resourcetype is very useful if the 
protocol or even users can't set new values. In the spirit of XML, clients 
should treat resource types (or MIME types for that matter) they don't 
know aboug as simple resources.

The type may be explicit with properties, but there are some potential 
problems with this approach. 1) the possibility of ambiguities resulting 
from sub-typing as Tim has pointed out,  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, and 3) perhaps reducing future protocol flexibility because 
we've allow too much semantics into clients that will restrict protocol 
evolution.




"Jim Amsden" <jamsden@us.ibm.com> wrote:
> The reason we can't introduce new resource types for
> all of the versioning resources is because we have to
> support down-level clients that only know about
> DAV:collection.

Not sure that I follow this argument, since 'down-level' clients will only
be looking for DAV:collection.

But I take this to mean you do not support extending DAV:resourcetype.

> For new resources that down-level clients couldn't
> possibly know about, workspaces, activities, baselines,
> etc., we don't have this restriction.

What do you mean?  I thought you just stated that we can't introduce new
resource types to retain forward compatibility.

> I agree with Greg and Tim. We should be as specific
> as we can about declared type and only compromise when
> required by interoperability considerations.

The type is made quite explicit by the supported live properties and
supported methods.  The only debate was how to marshal the 'type'.

Tim

Received on Tuesday, 19 June 2001 11:11:12 UTC