- From: Tim Ellison <Tim_Ellison@uk.ibm.com>
- Date: Wed, 27 Jun 2001 14:39:05 +0100
- To: DeltaV <ietf-dav-versioning@w3.org>
When a VERSION-CONTROL contains a DAV:version element, the href must refer to a version. The method precondition is "DAV:must-be-version". I haven't had the benefit of reading Jim W's slides -- but surely it doesn't take 52+ slides to describe DeltaV <G> Tim Alan Kent <ajk@mds.rmit.edu.au> wrote: > Slide 50 of Jim Whitehead's WWW 10 talk "Delta V: Adding > versioning to the web" has an example of creating a > workspace using MKWORKSPACE and then populating it using > VERSION-CONTROL commands. (These slides are great stuff > by the way. It makes it much easier to get an overall > feel for things.) > > The workspace URIs were things like /users/geoff/projectX/. > The original project file URIs were like /projectX/makefile. > The VERSION-CONTROL command then created /users/geoff/projectX/makefile > from /projectX/makefile. > > My reading of the DeltaV spec in Section 6.7 indicates that > VERSION-CONTROL is creating a > > "new version-controlled resource for an existing version > history". > > The examples the spec has then uses URIs like /his/12/ver/V3 > identifying a version from a history. Jim's example in his > slide is a version controlled resource (slide 52). > > Should the above text in the first paragraph of section 6.7 > of the spec be expanded to make it clear that the URI > identifies a version from the version history? Or can any > sort of resource be identified (version controlled, version, > version history, etc) as long as the version history can > somehow be identified? Or is the spec OK and the example > in the slides is wrong. > > Maybe the slides are a bit hand-wavy to get concepts across > more easily... The spec seems to state quite clearly that > a version URI should be supplied (it makes no comment about > using a version-controlled resource URI - unless its mentioned > somewhere else I have not found!).
Received on Wednesday, 27 June 2001 09:40:31 UTC