Re: Revision identifier and revisions label namespaces
ÿ (infonuovo@email.com)
Tue, 5 Oct 1999 17:50:12 -0700
From: <infonuovo@email.com>
To: <jamsden@us.ibm.com>, <ietf-dav-versioning@w3.org>
Date: Tue, 5 Oct 1999 17:50:12 -0700
Message-ID: <001501bf0f97$3de724e0$0100007f@conclave>
In-Reply-To: <85256801.00741E7F.00@d54mta03.raleigh.ibm.com>
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>