Re: Revision identifier and revisions label namespaces

jamsden@us.ibm.com
Wed, 6 Oct 1999 09:02:30 -0400 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256802.0047DE9A.00@d54mta03.raleigh.ibm.com>
Date: Wed, 6 Oct 1999 09:02:30 -0400
Subject: Re: Revision identifier and revisions label namespaces








"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 10/05/99 10:54:34 PM

To:   ietf-dav-versioning@w3.org
cc:

Subject:  Re: Revision identifier and revisions label namespaces




   From: jamsden@us.ibm.com

<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.
<jra>
I don't think the server-generated ids are likely to cause many collisions, so I
don't think we really have that big a problem here.
</jra>

   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.
<jra>
We may want to rethink this. Having a label quietly move from one revision to
another may not be what we want. Perhaps we should require a drop/add paradigm
rather than simply label. If not, then I still don't think this is much of a
problem. There may be other reasons a server can't support the label, so the
error could still occur.
</jra>

   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.
<jra>
Labeling a revision with the same label twice should return an error.
</jra>

   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.
<jra>
I believe the opposite. The likelihood of collisions occuring when adding a user
label is much smaller than the need to remember and distinguish label namespaces
when accessing the corresponding revisions. One accesses revisions a lot more
often than one labels them, and the consequences of the collision are minimal.
The user just has to pick another label.
</jra>

Cheers,
Geoff