From: jamsden@us.ibm.com To: ietf-dav-versioning@w3.org Message-ID: <85256802.0046C15D.00@d54mta03.raleigh.ibm.com> Date: Wed, 6 Oct 1999 08:52:07 -0400 Subject: RE: Revision identifier and revisions label namespaces This is not really the case. When a user checks out a revision a working resource is created. The workspace rules automatically select working resources over any other revision. If a user just checked in the resource and never labeled it, then a revision would exist that a user had no way to reference. The revision id isn't for internal server implementations (although servers are free to use it for whatever purposes they desire), its to ensure that all revisions of a versioned resource can be distinguished. Think of it as the initial label for a revision, one that can't be removed or moved, so you always know what you're going to get. infonuovo@email.com on 10/05/99 08:50:12 PM Please respond to infonuovo@email.com To: Jim Amsden/Raleigh/IBM@IBMUS, ietf-dav-versioning@w3.org cc: Subject: RE: Revision identifier and revisions label namespaces I agree with this. It makes no sense to have an user-meaningful label and a system-assigned unique identifier have anything to do with each other. One is for the internal integrity of the implementation and preservation of the model. The other is for what people or clients agree to use. It is also valuable to have both notions, though I don't know how you propose to have interoperability of the user-meaningful one. -- Dennis Dennis E. Hamilton - - - - - - - - - - - - - mailto:infonuovo@email.com tel: +1-206-779-9430 (gsm) http://www.infonuovo.com -----Original Message----- From: ietf-dav-versioning-request@w3.org [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of jamsden@us.ibm.com Sent: Tuesday, 5 October 1999 14:06 To: ietf-dav-versioning@w3.org Subject: Re: Revision identifier and revisions label namespaces <gmc/> If we put labels and identifiers in the same namespace, how do we answer a client that complains that it has to know the server dependent conventions for generating revision-id's before it can safely chose a label? What is the server benefit that would lead us to place such a burden on clients? <jra> If they're in separate namespaces, the client has the same burden. He still has to know which one is which and provide the proper indicator. The only way this can be avoided is if there are methods in which only one or the other (id or label) is valid. Then the client still has to know which to use. This was the reason for using one label namespace called revision names, and indicate there were two types: server generated and user generated. It shouldn't be too hard to keep these spaces separate, and collisions are easy to handle. The server will simply refuse to add the label to the revision and the user will pick something else. This is the same thing that would happen if the revision already had that label for any other reason. Nothing has to be remembered when the label is used in a target selector. All in all, I think this is easier for clients, not additional burden. </jra>