Re: URL's for specific revisions

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Sat, 23 Oct 1999 17:06:29 -0400 

Date: Sat, 23 Oct 1999 17:06:29 -0400
Message-Id: <9910232106.AA23925@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <1999Oct05.163500.1250.1342681@otismtp.ott.oti.com>
Subject: Re: URL's for specific revisions


   From: Tim_Ellison@oti.com (Tim Ellison OTT)

   I propose that we define the URL to a specific revision to be:

   revision_URL = history_resource_URL "/" <revision_identifier>

There are potentially several interesting "collections" associated
with a versioned resource, e.g. revisions, baselines, labeled-revisions.
So I advocate allowing the server to decide where these collections
will live, and to put the name of these collections as property
values of the versioned resource.

   Since history resources are non-versionable resources, the 
   history_resource_URL is not subject to selection rules.

In the latest spec, the concepts of "versioned resource" and "history resource"
have been merged, but there still are ways of accessing the "history
resource" properties, so your basic point still holds.

   This means that clients can 'globally' use a revision_URL to refer to a 
   specific versioned resource revision.

Yes.

   [Since the spec is quiet about where history resources are stored in the 
   namespace,

Quiet no longer ... "repository" resources are back (:-).

   I offer the following examples assuming that the server chooses 
   to store history resources as /history/<versioned_resource_id>,
   then:
       revision_URL = /history/<versioned_resource_id>/<revision_identifier>]

I'd modify this to be:

       rev_URL = /repoA/vrs/<versioned_resource_id>/revs/<revision_identifier>

where "vrs" and "revs" are segment names chosen by the server.

   For example:
	     http://foo.com/history/res23/rev42
	     http://foo.com/history/res81/rev1

http://foo.com/repoA/vrs/res23/revs/rev42
http://foo.com/repoA/vrs/res81/revs/rev1

   further, if a revision is a collection, then 'slashing though' it would be 
   allowed, and subject to the regular Target-Selection procedure, for 
   versioned collections,
   for example (assume res23 is a collection)
	http://foo.com/history/res23/rev42/member1/index.html

The current spec specifies that Target-Selection is "metadata" for
members of a repository, so you'd be able to slash through, but you'd
have to keep specifying revisions all the way down, e.g.:

http://foo.com/repoA/vrs/res23/revs/rev42/member1/revs/rev19/index.html/revs/rev44

which would pick rev42 collection of res23, and then pick revision 19
of the member named member1 from that, and then pick revision 44 of the
member named rev44 from that.

   This would make revisions members of a history resource rather than 
   properties.

Yes, as long as the server can pick where these collections are located
(and what their names are), I'm happy, and the above technique works.

Cheers,
Geoff