- From: <Tim_Ellison@uk.ibm.com>
- Date: Mon, 5 Feb 2001 15:42:56 +0000
- To: ietf-dav-versioning@w3.org
> From: "Lisa Dusseault" <lisa@xythos.com> > > > > 7) How do you distinguish between: > > > - A versionable resource > > > - A non-versionable resource > > > - A version-controlled resource > > > 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. > > One person's "resource type" is another persons "resource state". > Is "checked-out" a resource type or a resource state? Is "locked" > a resource type or a resource state. Is "under version control" > a resource type or a resource state. ... I'm not getting drawn into that one<g> > So either you need to carefully consider your choice of property > names (which you should do anyway), or carefully consider your > choice of "resource type names". I think the issue comes down to using the presence or absence of a property to define a resource type (to use the document's terminology), rather than using a property's value. Practically, it means issuing a PROPFIND and discarding some of the response and/or looking for errors. This feels like a secondary effect from the definition of those properties (although clearly it is a primary effect given that clients typically need to know the resource type). I say property names should be chosen carefully since extensions may not be able to use the property names DAV:checked-out and DAV:checked-in without other properties that distinguish the resource type. > I agree that determining type by the absence of properties is > sub-optimal; I'd say it's not very reliable. > > How is it any less reliable than looking for a particular value > in a "resourcetype" property? I agree that Lisa's use of the word "unreliable" is incorrect here, but I'd say that looking for a property value is more direct and extensible. Tim
Received on Monday, 5 February 2001 10:45:16 UTC