- From: Lisa Dusseault <lisa@xythos.com>
- Date: Fri, 2 Feb 2001 12:19:54 -0800
- To: <Tim_Ellison@uk.ibm.com>, <ietf-dav-versioning@w3.org>
> > 7) How do you distinguish between: > > - A versionable resource > > - A non-versionable resource > > - A version-controlled resource > > > > Let's say the client wishes to present a simple UI which > > lists all the resources in a collection, and can tell > > what each resource is, allowing operations like "show me > > the version history" or "turn versioning on" to be > > available only when appropriate. How, exactly, is this > > accomplished? What property is retrieved? > > Good question. > A versionable resource will answer with (at least) Allow: > VERSION-CONTROL > to an OPTIONS request, a non-versionable resource will not. A > version-controlled resource is the only resource with a > DAV:checked-in or > DAV:checked-out property. > > There was some debate a while ago about making the resource > types explicit, > with various methods sugested. I have to say that > determining type by the > presence or absence of properties is sub-optimal since, among > other things, > it makes for careful consideration when defining new resources with > overlapping property names. I agree that determining type by the absence of properties is sub-optimal; I'd say it's not very reliable. I'd point out another problem: in order to create the kind of GUI I described, the client would have to: - Issue a depth:1 PROPFIND request to find all the resources that have a DAV:checked-in (or checked-out) property. If they do, consider them VCRs. - Issue an OPTIONS request to every non-VCR, to find out whether it can be versioned or not. This is an order(N) operation, just to show a decent directory listing. Depth is not supported on OPTIONS requests, according to RFC2518: "The Depth header is only supported if a method's definition explicitly provides for such support." This is a serious client issue. Please address... Lisa
Received on Friday, 2 February 2001 15:20:52 UTC