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

I second what Jim's saying.  Furthermore, I'd point out that server
implementations differ.  Servers may not implement all live properties or
methods that a client expects.  Some servers may add new, custom live
properties.  Does that change the type and make the client unable to
confidently deal with the resource?

I've heard the argument here before that the spec isn't done until you've
taken out anything that needs to be taken out.  Taking that too literally
would be abuse of a guideline that has proved useful to us.  Let's be a
little less dogmatic:  the intent of that guideline is to encourage spec
writers to pare down the sets of features and options, to reduce complexity.
Or to think of it another way, to improve simplicity.

So ask yourself if removing resource types in DeltaV improves simplicity.
It does not.  The resource type is a piece of information that is easily
provided by the server and makes things immensely simpler for the client.
It is not an option, therefore clients can rely on it.  It improves
robustness and can foster better extensions in the future.  It should
remain.

Lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden
> Sent: Thursday, June 21, 2001 7:16 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Removing the DAV:activity and DAV:version-history and
> DAV:bas eline resource type values
>
>
> I agree with Geoff that *most* new resource types do result in at least
> one new method and/or property. But this is fundamentally a poor thing to
> depend on as we know there can be (and therefore probably will be)
> subtypes that don't add new methods or properties, but only override
> behavior of their superclass. By not resolving the resource type issue to
> support such situations, we may be just putting the problem off in such a
> way that it will need to be solved in some very different manner by some
> future protocol extension. This is what keeps nagging at me.
>
>
>
>
> "Clemm, Geoff" <gclemm@rational.com>
> Sent by: ietf-dav-versioning-request@w3.org
> 06/21/2001 08:38 AM
>
>
>         To:     ietf-dav-versioning@w3.org
>         cc:
>         Subject:        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 Thursday, 21 June 2001 12:51:31 UTC