Re: Revision identifier and revisions label namespaces

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 5 Oct 1999 22:54:34 -0400 

Date: Tue, 5 Oct 1999 22:54:34 -0400
Message-Id: <9910060254.AA14487@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <85256801.00741E7F.00@d54mta03.raleigh.ibm.com>
Subject: Re: Revision identifier and revisions label namespaces


   From: jamsden@us.ibm.com

   <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?

   <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.

<gmc/> I imagine that the usage of server assigned immutable identifiers
are sufficiently distinct from the usage of client assigned mutable
labels that a client would in any case need to know when it was using
one and when the other.

   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,

<gmc/> For any given server, I agree that there could be a simple
rule that partitions the namespace between identifiers and labels.
If you have a client trying to run against several servers,
it could be frustrating to keep colliding with different server
conventions.

   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.

<gmc/> You never collide with a label ... you just cause that label
to be moved to the revision you specified.  But you can collide with
an identifier, since that is server assigned and cannot be assigned
(or reassigned) by a client.

   This is the same thing that would
   happen if the revision already had that label for any other
   reason.

<gmc/> That is a good point, but it is still a very different case
(one is a collision that fails the label request ... the other moves a
label that someone was using for something else).  Also note that the
label problem occurs only if someone has chosen that exact label for a
revision of that versioned resource.  The identifier collision occurs
whenever your label has the syntactic shape of an "identifier" for
that server, even if there is no such identifier on that versioned
resource, or even on any versioned resource.

   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>

<gmc/> I believe that benefits of avoiding label/identifier collisions,
combined with the likelihood that a client would need to distinguish
when it is using a label vs. and identifier anyway, outweighs any benefits
that might result from unifying the namespaces.

Cheers,
Geoff