Re: Revision identifier and revisions label namespaces

jamsden@us.ibm.com
Thu, 7 Oct 1999 09:48:14 -0400 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256803.004BF7FF.00@d54mta03.raleigh.ibm.com>
Date: Thu, 7 Oct 1999 09:48:14 -0400
Subject: Re: Revision identifier and revisions label namespaces



I think Geoff's example highlights the need for a single namespace. It is not
uncommon for objects to have multiple candidate identifiers. Each candidate
identifier conveys some information about the object's identity while carrying
interesting state. So far, the only differences we have identified between an id
and a label is that the id is assigned by the server when the revision is
created (i.e., the revision must be identifiable), and it can't be changed
(i.e., it must not be possible to make a revision unidentifiable). In all other
cases, the id and labels are treated the same. There are two cases:

1. ids and labels are in separate namespaces:
+ they never collide
+ servers have greater degrees of freedom in assigning ids
- label collisions do still occur though as a user can attempt to assign the
same label to a revision more than once
- ids are not meaningful across servers
- users have to distinguish ids from labels on all accesses (including through
workspace RSRs)
- the protocol is more complicated as it must define and manipulate multiple
label namespaces

2. ids and labels are in the same namespace
- there is a possibility for user labels to collide with server ids requiring
the user to specify a different label
- servers should pick id naming schemes that minimize the potential for
collisions resulting in limited choice
- ids are still not meaningful across servers (or replications)
+ users do not have to distinguish ids from labels on any access
+ all revision identifiers (ids and labels) are handled uniformly by the
protocol simplifying the protocol

It seems to me the last two points far out weight the previous as labels are
used to access resources a lot more often then they are assigned to resources. I
believe the protocol is simpler if there is one revision namespace, client
applications are simpler, users have to know less information to access
revisions, and the possibility and consequences of collisions are minimal and
exist anyway.

What problem is solved, other than id/label collisions, by having separate
namespaces. Seems like a relatively high cost for little gain.





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

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

Subject:  Re: Revision identifier and revisions label namespaces



Ooops.  I sent off the message before finishing it.  I just had one
last section to respond to:

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

This is a very good point.  It shows up for example when a user asks
the client to fetch revision "23".  The client has to ask the user
whether they want the revision labeled "23" or the revision with id
"23" (the resource potentially could even have both, identifying
different revisions).

Overall though, I still think the benefits of keeping the namespaces
disjoint outweigh the costs.

Cheers,
Geoff