- From: Lisa Dusseault <lisa@xythos.com>
- Date: Mon, 5 Feb 2001 14:58:32 -0800
- To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <ietf-dav-versioning@w3.org>
> Note: Lisa asks a bunch of great questions here. They are all > good candidates for FAQ entries. For the moment, I'll just > do the easy thing and answer them in email. I'll try to get > this info transcribed to the FAQ. If anyone else has a chance > to enter this information in the FAQ, that would be greatly > appreciated! Two of the questions I asked so far seemed to be answered with simple clarifications. I've added those to the FAQ. Many of the questions are NOT suitable for being answered in the FAQ. They clearly ask for normative declarations (rather than unstated assumptions), which belong in the spec, or rewording of text in the spec. > But there is no "implicit" pass through by a version-controlled > resource. This is explicitly stated in section 2.1. > > To recap: When new kinds of resources that have targets, > like "Direct Reference Resources" or "Version controlled Resources" > (DRR/VCR), are exposed to clients that are not familiar > with the new > kinds of resources, it's often beneficial to allow some of > the methods > the client may send to "pass through" to the target of DRR/VCR. > > A version-controlled resource does not have a "target". We > explicitly got rid of this term because it was misleading people > into thinking just what you describe above. Pass through behavior > only occurs when explicitly requested by a header, or when > explicitly defined in the semantics of a new method. I'd like to believe you ;) but the draft states: "A PUT or PROPPATCH to a version-controlled resource with the DAV:auto-version property set will automatically check out that resource prior to executing the PUT or PROPPATCH. If that resource is write-locked, the resource remains checked-out until the resource is unlocked, at which time the resource is checked in and a new version is created in the version history of that resource." That to me is "passthrough", even without the label target, because it bypasses the content or properties of the VCR in order to create a new version. How am I supposed to change the properties of the VCR itself? The previous paragraph states: "In order to use methods like PUT and PROPPATCH to directly modify the content or dead properties of a version-controlled resource, the version-controlled resource must first be checked out. When the checked-out resource is checked in, a new version is created in the version history of that version-controlled resource. The version that was checked out is remembered as the predecessor of the new version." That is unacceptable. It's completely unacceptable to create a new version of a resource, just in order to be able to modify a property like 'Last-published-version' on the VCR. For the sake of conciseness, let's call this a "global" property: it applies to all versions, and can't have different values on different versions. In order to modify a global property, does a new version have to be created? Even though nothing changed on the old version? (the only change, conceptually, is a dead property on the VCR). If I understand the model correctly, that won't work because the properties of a checked-in VCR are the same as the properties of the checked-in version. So global properties can't be placed on VCRs at all. Where do global properties go, then? You state that rather than put global properties on the VCR, the client ought to put them on the VH: > It sounds like you're talking about properties on the version history > resource. Your server of course must then support the version history > option, but then you PROPPATCH the version history resource > just as you > would PROPPATCH any other resource. That's unacceptable. First, as you point out, the server must support an extra resource, the VHR. Then, in order to present a directory listing with the value of a global property like "Last-published-version" for each of n VCRs in a directory, the client would have to issue a depth:1 PROPFIND request to find all the URLs to the VHRs, then issue n PROPFIND requests, one to each VHR independently, to get the values of "Last-published-version". However, the real showstopper is the lack of resource transparency. Global properties, like "author" from Dublin Core, or "Editor-in-Chief", are hidden away in VHRs. That means that versioning-unaware clients cannot interoperate with versioning clients on the same set of documents. They can't even PROPFIND a set of VCRs to get properties which ought to exist. lisa
Received on Monday, 5 February 2001 17:59:47 UTC