- From: Rick Rupp <rick.rupp@merant.com>
- Date: Wed, 20 Jun 2001 08:59:18 -0700
- To: "Clemm, Geoff" <gclemm@rational.com>, ietf-dav-versioning@w3.org
Lets move forward and remove it from the protocol. At 11:59 PM 6/19/01 -0400, Clemm, Geoff wrote: >Actually, I shouldn't have used the word "variant" since that has a >specific HTTP meaning (an alternative form of a resource content, >such as another language), and I was using it to mean "a resource that >will have a separate version history, but which is based on a version >from another version history". > >I think the working group consensus is to just get rid of it until >it gets more support, so unless you are strongly attached to it, >I'd like to resolve this particular issue by pulling DAV:precursor-set >from the protocol. > >Cheers, >Geoff > >-----Original Message----- >From: Rick Rupp [mailto:rick.rupp@merant.com] >Sent: Tuesday, June 19, 2001 8:08 PM >To: ietf-dav-versioning@w3.org >Subject: Re: Actually, you don't need COPY or MOVE, what you really seem >to want is CLONE. > > >I agree with the group that there are other ways to track relationships >between version histories. If this is the only use case for the >precursor-set and the consensus of the group is it should be dropped, I'm >okay with this decision. > >I understand what a variant is however I don't fully understand how the >precursor-set is used to create one in a workspace. If that is how variants >are created then I recommend the precursor-set be kept and moved from the >version-control feature into the workspace feature. > >At 10:34 AM 6/19/01 -0400, Jim Amsden wrote: > >I guess I agree with John. This sort of information is generally kept in > >comments or application specific properties. The question we have to ask > >ourselves is if there is any need to have precursor information available > >in an interoperable way. I don't know off the top of my head any other > >system that supports this, but it could be something I just never used. > > > >I also agree with Geoff in that there are good arguments either way. > >However I'd lean in the direction of leaving things out if there is any > >doubt. They can always be added in later when we have more experience and > >the use cases are more crisp. We don't want to hold up the protocol on > >such issues either if we can help it. > > > > > > > > > >I still can't see where it is useful to know about two different version > >histories, one that you have poor information on (the source of the > >COPY) and an old version history that is no longer relevent to the > >actual content (since you overlayed it). > > > > > > > > > -----Original Message----- > > > From: ietf-dav-versioning-request@w3.org > > > [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of John Hall > > > Sent: Monday, June 18, 2001 8:30 PM > > > To: 'Rick Rupp'; ietf-dav-versioning@w3.org > > > Subject: RE: [ietf-dav-versioning] <none> > > > > > > > > > I disagree. > > > > > > I see no difference between creating a new version from > > > scratch and copying data from somewhere else to create a new > > > version from scratch. If I open file1 and then do a save-as > > > on file2, the server doesn't know and precussor isn't set in > > > any case. So why is it so important to know that someone > > > grabbed a copy of file1's current version and copied it to > > > file2 without editing it first? If you really want the > > > version history, use MOVE not COPY. > > > > > > Do you have a 'for example' use case where that origin > > > information is valuable? And would it still remain valuable > > > after a few more edits were done? > > > > > > > > > > > > > -----Original Message----- > > > > From: ietf-dav-versioning-request@w3.org > > > > [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Rick Rupp > > > > Sent: Monday, June 18, 2001 5:39 PM > > > > To: ietf-dav-versioning@w3.org > > > > Subject: [ietf-dav-versioning] <none> > > > > > > > > > > > > The precursor-set property seems to be an important concept > > > > of a versions > > > > history. Without it there is no indication that a version has a > > > > relationship to another version history. > > > > > > > > I don't think it will be unusual for a client to create a new > > > > version by > > > > copying from a different version history. Will it be > > > > important to know the > > > > new version came from a different version history? I think > > > > the answer is > > > > yes and the precursor-set facilitates this. > > > > > > > > > > > > > > > > > > > > >
Received on Wednesday, 20 June 2001 12:00:54 UTC