- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 27 Jun 2001 14:11:48 -0400
- To: DeltaV <ietf-dav-versioning@w3.org>
From: Alan Kent [mailto:ajk@mds.rmit.edu.au] 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". Yes. But since the VCR needs to identify a particular version from that version history, a particular version is required when you create the new VCR. 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). Jim's example doesn't display the actual syntax, but describes the result, so it leaves out this kind of detail. 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? The introductory text gives you the motivation for the semantics, and adding in this kind of detail risks blurring the overall picture. Or can any sort of resource be identified (version controlled, version, version history, etc) as long as the version history can somehow be identified? No, only a version. Or is the spec OK and the example in the slides is wrong. I'd describe the example in the slides as "simplified" rather than "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 Yes. (it makes no comment about using a version-controlled resource URI - unless its mentioned somewhere else I have not found!). Nope, no hidden semantics. One of the benefits of the rigorous precondition/postcondition approach, is that you don't have to worry about semantics being scattered througout the protocol text ... if it's not in the preconditions or postconditions, it ain't so. Cheers, Geoff
Received on Wednesday, 27 June 2001 14:16:04 UTC