Re: Target selector

Jeff McAffer OTT (Jeff_McAffer@oti.com)
Fri, 13 Aug 1999 17:00:05 -0400 

From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Aug13.165300.1250.1288308@otismtp.ott.oti.com>
Date: Fri, 13 Aug 1999 17:00:05 -0400
Subject: RE: Target selector


I don't recall the rationale saying that version-collections (VCs) can   
only hold versioned-resources.  This seems overly/needlessly restrictive.   
 Saying that / cannot be a version-collection is, as we say round here,   
"somewhat less than optimal".

If we allow non-versioned-resources in VCs, we need to define the   
semantics of deep checkin of a versioned collection with non-versioned   
and non-versionable resources.  How about this:

 - non-versionable resources are ignored but perhaps logged in the   
response to the CHECKIN request.
 - the behaviour for non-versioned but versionable resources is subject to   
a property of the resource.  If it is "auto-versioned" then the   
non-versioned resource is silently versioned.  If this property is false,   
an error is returned identifying the non-versioned-resource as the cause.   
 Users can then checkin that resource and retry the operation.  If the   
property is not set it should default to the true behaviour (IMHO)

Jeff


> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@atria.com]
> Sent: Friday, August 13, 1999 3:03 PM
> To: ietf-dav-versioning
> Subject: Re: Target selector
>
>
>
>
> A resounding "yes" to all the above.  This is so eminently
> worth saying,
> that I propose we add words to this effect to the spec itself.
>
> Cheers,
> Geoff
>
> > From Tim_Ellison@oti.com Fri Aug 13 14:44 EDT 1999
> > From: Tim_Ellison@oti.com (Tim Ellison OTT)
> > To: gclemm@tantalum.atria.com (Geoffrey M. Clemm)
> > Cc: ietf-dav-versioning@w3.org (ietf-dav-versioning)
> > Mime-Version: 1.0
> > Date: Fri, 13 Aug 1999 14:44:05 -0400
> > Subject: Re: Target selector
> >
> >
> > >Since a workspace is not a versionable resource, there is no need
> > >for a workspace to resolve a workspace URL.
> >
> > and ... (just to say it out loud) ... since versioned
> collections can only
> > contain versioned resources, the workspace URL cannot imply
> any collection
> > that requires a workspace ... and therefore the collection
> known to the
> > server as "/" cannot be a versioned collection.
> >
> > Tim
> >
>
>