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

"Jim Amsden" <jamsden@us.ibm.com> wrote:
> 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.

I tried that and WebFolders displayed the resource as a Folder (even if the
DAV:resourcetype was, say, <DAV:activity>.  Trying to open the WebFolder
resulted in no resources.  So it is broken in as much as it displays the
'wrong' icon.

My recollection was that people decided that WebFolders could change to do
the "right thing".

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

Not so for workspaces.  A workspace is-a collection, but I take your point.

> The problem is that some new resources might be a kind
> of collection where down-level clients could do something
> with them.

Agreed.  Again, workspace would be a good example of this.

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

Agreed.  WebFolders does not do this today.

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

Geoff's argument was that if a resource is a sub-type then clients that
treat it as a super-type will still do the right thing (without being able
to use its sub-type capabilities).

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

No, they just need to look and see if the properties and/or methods are
supported to correctly type the resource.  The latest draft of the spec has
an appendix that spells this out.

> and 3) perhaps reducing future protocol flexibility because
> we've allow too much semantics into clients that will restrict
> protocol evolution.

Again, no semantics is required to correctly 'type' a resource.

Tim

Received on Tuesday, 19 June 2001 12:07:18 UTC