- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 11 May 2001 23:13:07 -0400
- To: ietf-dav-versioning@w3.org
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] [I did send this mail once, but it hasn't appeared, so here's attempt #2] I didn't get the mail, so it probably is good you resent. --------------------------- The issue of determining a versioning resource's classification based on the absence (or otherwise) of properties has been raised before on the list. Recently however, (in other contexts) people have shifted in favour of extensions to <DAV:resourcetype> to convey more 'type' information. Not me ... I think you should just look in the DAV:supported-method-set and DAV:supported-live-property-set for the methods or properties that you care about. If it supports the methods and properties you care about, who cares what's in the "resourcetype" field (:-). But then again, if you want to add a bunch of redundant information to the resourcetype field, I guess I don't really care all that much (although it does violate the Goland rule of "you are done when there is nothing left to cut out" :-). In support of this shift of opinion, here's my renditioning of how a client currently determines the resource classification (if, for example, if a client were given a URL in a property with no other information) in a versioning world. To get an accurate classification the client has to issue a PROPFIND then look at the results as follows (hopefully my layout is not too cryptic): >>REQUEST PROPFIND /foo HTTP/1.1 Host: bar.com Content-Type: text/xml; charset="utf-8" Content-Length: xxx <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:resourcetype/> <D:auto-checkout/> <D:checked-in/> <D:checked-out/> <D:version-name/> <D:workspace-checkout-set/> <D:baseline-controlled-collection/> <D:subactivity-set/> </D:prop> </D:propfind> Actually, you can get all the information you need from the DAV:supported-live-property-set property, e.g.: >>REQUEST PROPFIND /foo HTTP/1.1 Host: bar.com Content-Type: text/xml; charset="utf-8" Content-Length: xxx <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:supported-live-property-set/> </D:prop> </D:propfind> Interpreting the results -------------- Key: The major classifications are listed below from (1) to (8). Each entry marked with a plus-sign can exist in a checked-in xor checked-out state. + <DAV:checked-in> defined -- the resource is checked-in. <DAV:checked-out> defined -- the resource is checked-out. Note that whether or not a resource is checked-in or checked-out is normally considered part of its "state" rather than part of its "type" (which just illustrates the vague boundary between "state" and "type" :-). If you wanted to know whether or not a resource was checked-in or checked-out, then you would have to PROPFIND for checked-in and checked-out. Each entry marked with an astrix can exist as a collection resource xor a non-collection resource. * <DAV:resourcetype> value is not <DAV:collection/> -- the resource is not a collection. <DAV:resourcetype> value is <DAV:collection/> -- the resource is a collection. Yes, if you wanted to find out whether or not a resource is a collection, you would need to query DAV:resourcetype. But for all the "types" of resources introduced by DeltaV, the DAV:supported-live-property-set gives you all the info you need to determine the type of the resource. (1+*) Version-controlled resource. <DAV:auto-checkout> defined (appears in DAV:supported-live-property-set) (2*) Version. <DAV:version-name> defined (appears in DAV:supported-live-property-set) (3) Version history. <DAV:resourcetype> value is <DAV:version-history/> (or look to see if DAV:root-version is supported) (4) Workspace. <DAV:resourcetype> value is <DAV:collection/> <DAV:workspace-checkout-set> defined Don't care about DAV:collection. Just see if DAV:workspace-checkout-set is in DAV:supported-live-property-set. (5*) Working resource. <DAV:checked-out> defined <DAV:auto-checkout> *not* defined (appears and does not appear, respectively, in DAV:supported-live-property-set) (6+) Version-controlled configuration. <DAV:baseline-controlled-collection/> defined (appears in DAV:supported-live-property-set) (7) Baseline. <DAV:resourcetype> value is <DAV:baseline/> (or look to see if DAV:baseline-collection is supported. (8) Activity. <DAV:subactivity-set> defined. (appears in DAV:supported-live-property-set) Observations ---------- (i) For the most part we only care if a property is defined - i.e., it exists, and not what it's value is. There is currently no way to ask this question in WebDAV. In DeltaV there is ... DAV:supported-live-property-set. (ii) It would seem that activities should have a <DAV:resourcetype> of <DAV:activity>, but I didn't see that in the -15 spec. It appears in the postcondition of MKACTIVITY, but I'm happy to mention it in section 13.1 as well. (iii) The only way I could see to distinguish a workspace from a 'regular' collection was the presence of <DAV:workspace-checkout-set/> which it would seem is likely a very expensive property to query. Good thing that we have DAV:supported-live-property-set so that the server doesn't actually have to compute the value (:-). Conclusions --------- (a) We should extend <DAV:resourcetype> to provide all this classification information in a single property. You get all the information you need in a single property today (DAV:supported-live-property-set). Or if you care whether or not something is a collection, you can also look at DAV:resourcetype. (b) How about extending <DAV:propname/>? such as <DAV:propname> <DAV:checked-out/> </DAV:propname> then the client would get back just the name or a 404 to determine if it exists. Or (as I'm sure you can predict I will say ... :-) how about just using DAV:supported-live-property-set? Cheers, Geoff
Received on Friday, 11 May 2001 23:13:41 UTC