W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Removing the DAV:activity and DAV:version-history and DAV:bas eline resource type values

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 21 Jun 2001 08:38:16 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103625246@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
Nice summary, Stefan!

One addendum: Notice that the binding protocol addresses
the 2518 omission of a few critical collection operations
(BIND, UNBIND, REBIND).  If we merge the "bind"
protocol into the next draft of 2518 (which we should do),
then DAV:supported-method-set allows you to distinguish a
collection from a non-collection.  Arguably, there are a few
key collection properties (e.g. DAV:child-count) that should
be added as well.  My experience is that every new type
of resource normally brings at least one new method or property
in with it.

Also note that Tim recently posted on this thread:
  I support taking them out.  We don't need them.

So that puts Tim and me pretty much in the same camp.


-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Thursday, June 21, 2001 4:17 AM
To: ietf-dav-versioning@w3.org
Subject: AW: Removing the DAV:activity and DAV:version-history and
DAV:baseline resource type values

Well, I'm amazed how much energy is spend here on that
DAV:resourcetype thing and MS WebFolders.

IF (and that's the point worth discussing) deltaV introduces
_types_ of resources, then it can define a protected live
property DAV:subtype/DAV:interface/DAV:reallyresourcetype,
put it's new type definitions there and leave DAV:resourcetype
as it is. (Include the new property in an <allprop/> response,
MS Webfolder will never see it, it does not use allprop.)

The alternative is to have no new types and introduce only
new live properties, which a client can learn about with

I got the impression somehow that Geoff is in favour of the latter
one, Tim is undecided, Greg is opposed to it, and the rest
is trying to figure out what DAV:supported-live-property-set
means, how it is interpreted and how it might survive future

What other examples beside deltaV do we have in other drafts:
- Redirect Refs: -> new DAV:resourcetype + property
- Ordered Collections -> new property
- Binding: none
- DASL: none
- ACL: none

Best Regards,


> -----Ursprungliche Nachricht-----
> Von: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Jim Amsden
> Gesendet: Mittwoch, 20. Juni 2001 23:21
> An: ietf-dav-versioning@w3.org
> Betreff: 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 Thursday, 21 June 2001 08:32:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC