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

Neither Tim nor I ever used the interaction of DAV:resourcetype
with Web Folders as a reason to not use DAV:resourcetype, so although I
agree that the case is closed on the Web Folders treatment of
DAV:resourcetype (or at least, was closed until JimA raised it
again :-), this has little or no bearing on the discussion
of whether adding new values to DAV:resourcetype or using
DAV:supported-*-set
is a better way for clients to interoperate with DeltaV servers.

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Friday, June 22, 2001 5:29 AM
To: Clemm, Geoff; ietf-dav-versioning@w3.org
Subject: AW: Removing the DAV:activity and DAV:version-history and
DAV:bas eline resource type values


One correction though:

ACL (0.6) defines resource type DAV:principal and for collection
principals it reports:

<D:resourcetype>
  <D:collection/>
  <D:principal/>
</D:resourcetype>

So, all arguments with or without Webfolders for or against putting
additional things into DAV:resourcetype are void, unless someone
throws all the supported-* stuff into the ACL spec as well (it's
on last call, in case someone missed that).

My expectation would be that clients have to deal at least as often
with ACL WebDAV servers than DeltaV WebDAV servers.

Case closed. There is not additional burden on clients with deltaV
resourcetype extensions.

//Stefan

> -----Ursprüngliche Nachricht-----
> Von: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Clemm, Geoff
> Gesendet: Donnerstag, 21. Juni 2001 14:38
> An: ietf-dav-versioning@w3.org
> Betreff: RE: Removing the DAV:activity and DAV:version-history and
> DAV:bas eline resource type values
>
>
> 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.
>
> Cheers,
> Geoff
>
> -----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
> DAV:supported-live-property-set.
>
> 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
> extensions.
>
> 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,
>
> Stefan
>
> > -----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 Friday, 22 June 2001 18:53:42 UTC