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

Lisa,
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, and we know this causes problems for some servers. 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. 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. 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.

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. This works *except* for (sub)types that 
don't introduce additional properties. Its a little more inconvenient, but 
perhaps won't be that different if we really solved the type hierarchy 
problem. The end result is that DAV:resourcetype is pretty useless.

Geoff, do we still have a potential problem with the introspection 
approach in cases where new types don't introduce new properties? 
Unfortunately type depends on more than signature, it also depends on 
behavior, and this isn't captured in the supported properties in all 
cases. 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.





"Lisa Dusseault" <lisa@xythos.com>
06/20/2001 04:32 PM

 
        To:     "DeltaV" <ietf-dav-versioning@w3.org>, "Jim Amsden" <jamsden@us.ibm.com>, 
"Jim Whitehead" <ejw@cse.ucsc.edu>
        cc: 
        Subject:        RE: Removing the DAV:activity and DAV:version-history and DAV:baselin   e 
resource type values

 


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

I thought we had rather strong guidance that working around bugs in a 
single
implementation was NOT recommended.  Clarification, Jim?

I'd also point out that frequently it will be OK even with buggy clients 
to
introduce new resource types.  For example, I don't suppose it will be 
that
easy for non-versioning-aware clients to stumble across URLs of 
collections
of version-histories, activities, baselines and workspaces.  Not all of
these new resources are even browsable, and they may not appear in any
regular URL space that regular clients are expected to use.

lisa

Received on Wednesday, 20 June 2001 17:21:33 UTC