- From: <Tim_Ellison@uk.ibm.com>
- Date: Mon, 20 Nov 2000 09:43:39 +0000
- To: ietf-dav-versioning@w3.org
For each "versioned collection" I meant to say "collection version", thanks for picking that up. Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on 2000-11-17 08:00:35 PM Please respond to "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> To: ietf-dav-versioning@w3.org cc: Subject: Re: Working collections From: Tim_Ellison@uk.ibm.com We agreed that URLs to versions exist outside the normal DAV namespace. This is concept is variously reflected in the spec as virtually hosted URLs (http://repo.webdav.org/his/23/ver/42) and 'stolen' parts of the root collection namespace (e.g. http://www.webdav.org/repo/wr-157.html). Clients should not, therefore, expect to be able to construct new URLs based on these server maintained URLs (i.e. removing / adding segments to reach other resources). Yes. Q1: We know that a versioned collection is a mapping from names to version histories. Actually, we no longer use the ambiguous "versioned collection" terminology, so we actually don't know that (:-). We do know that a collection version is a mapping from names to version histories. We also know that a collection version selector is a mapping from names to other version selectors (and to resources that aren't under version control). So when you check out a versioned collection what can you do with the resulting working collection? Working on a checked out version selector for a collection is well defined, so I assume you mean "when you check out a collection version, what can you do with the resulting working collection"? You are right that this is not defined, and does not follow from the semantics of checked-out version selectors, so this needs to be fixed. My first choice would be your subsequent answer, i.e. that "you can only check out a collection version selector, and not a collection version". Greg doesn't like that answer, so it's probably worth exploring what a working collection might be (although I haven't given up hope in trying to get Greg to just use workspaces and checked out version selectors :-). Are you constrained to creating members that bind to histories only? If we allow it working collections, then being constrained to creating members that bind only to histories makes sense. Are you prevented from creating new bindings at all? I don't see any reason for this constraint. Q2: Can you delete bindings from a working collection -- presumably yes since if you can't change a working collection's members you can only use them to change properties? (There is clearly a good case for checked out collection version selectors). Yes. When the server sees a URL to a working collection, say of the form http://repo.webdav.org/vr/9/wr/1/foo it can 'know' about the form of these URLs to determine that everything up to 'foo' is the URL to the working collection and 'foo' is the member of that collection, but there would be (typically) no relationship between that URL and the URL of the history resource that 'foo' is currently bound to; so it would not be possible to slash-through 'foo' to reach other resources. Correct, which is why I find working collections of negligible value (compared to checked-out collection version selectors, which you can slash-through). Cheers, Geoff
Received on Monday, 20 November 2000 04:46:49 UTC