RE: [ietf-dav-versioning] <none>

OK, I officially recuse myself from this issue.  Every time I read
a post from one side or the other, I find myself agreeing with
whoever posted last (which means I currently agree with John, but
I'm sure it won't take much to switch me back again :-).

So the only thing I am against is "MAY".  Either we keep it in the
protocol as a MUST (i.e. MUST be set on COPY), or we delete it.
Other than that, just tell me which side won (:-).

Cheers,
Geoff


-----Original Message-----
From: John Hall [mailto:johnhall@evergo.net]
Sent: Monday, June 18, 2001 11: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 Tuesday, 19 June 2001 00:51:59 UTC