W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Resource class

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 11 May 2001 23:13:07 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B102EF5BD9@SUS-MA1IT01>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT