Separate Revision Id and Label Namespaces: Impact on the Protocol
Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Sun, 24 Oct 1999 08:28:56 -0400
Date: Sun, 24 Oct 1999 08:28:56 -0400
Message-Id: <9910241228.AA24231@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <85256808.0051DD87.00@d54mta03.raleigh.ibm.com>
Subject: Separate Revision Id and Label Namespaces: Impact on the Protocol
Currently, the impact on the protocol of having separate revision label
and id namespaces is the presence of two collection properties for
versioned resources (i.e. DAV:revisions and DAV:labeled-revisions)
instead of one, and the need for a differentiator in the Target-Selector
header, i.e.:
Target-Selector: label foo
Target-Selector: id foo
Does anyone see any other impact?
I'll note that we probably want two collections anyway, since one has
repeated members and is writable by the client (DAV:labeled-revisions),
while the other has every member exactly once (DAV:revisions). This
makes them useful for different purposes, so it is probably desireable
to keep them separate.
I'll also note that currently we have a differentiator in the
Target-Selector header anyway, to clearly differentiate between
workspace values and revision-id/label values, i.e.
Target-Selector: workspace /x/y
Target-Selector: id foo
and to indicate when we want the versioned resource itself:
Target-Selector: metadata
On the other hand, if we split Target-Selector into two headers:
Workspace and Revision-Selector, and do not allow the "metadata"
value in Revision-Selector, then we would not need a differentiator
in the Revision-Selector header if label's and id's are in the same
namespace (we still would need one in the Workspace header though).
And as a final note, I remain neutral on this topic. I just wanted to
lay out the details of the impact on the current protocol, in preparation
for a lively debate in Washington (:-).
Cheers,
Geoff