AW: Resource class

This touches on an issue I (the guy with the webdav [maybe caching
a little] proxy) have with discovering type and status of a WebDAV resource.

As Geoff made quite clear, DAV:supported-live-property-set contains all
there is to know about a versioned resource. But what about versionable
resources? Will/Should they have any versioning props apart from
DAV:supported-method-set with at least VERSION-CONTROL as content?

How is supported-method-set supposed to work in conjunction with other
WebDAV extensions (ordered collections, reference, etc.) Will all those
methods be mentioned there as well? Won't deltaV become a necessary
functionality for these extensions, then?
If not, does OPTIONS then remain a better place to look for methods?

Stefan
(won't like resource type
DAV:checked-out-external-reference-to-ordered-collection)

> -----Ursprüngliche Nachricht-----
> Von: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Clemm, Geoff
> Gesendet: Samstag, 12. Mai 2001 05:13
> An: ietf-dav-versioning@w3.org
> Betreff: RE: Resource class
>
>
>    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 Monday, 14 May 2001 05:15:19 UTC