RE: PROPFIND allprop with more properties (was AW: Resource class )

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, May 22, 2001 6:38 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: PROPFIND allprop with more properties (was AW: Resource
> class )
>
>
>    From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>
>    Oops. Our understanding was that DAV:propname behaves analog to
>    DAV:allprop and will not include the versioning properties. I see
>    that "propname" is not mentioned in
>    ietf-deltav-versioning-15. Could you clarify?
>
> With the versioning protocol, everything stated in HTTP-1.1 (RFC-2616)
> and WebDAV (RFC-2518) holds unless explicitly extended or modified by
> the versioning protocol.  Since nothing is said about DAV:propname, it
> has the behavior defined in RFC-2518, i.e. it lists all the properties
> of a resource (including the versioning properties).

My two cents:

- looking at RFC2518 alone, a sever implementor might be tempted to
implement <propname> as returning *exactly* those properties that <allprop>
will return (I did). If this is not the case with DeltaV, it might be a good
idea to make that explicit.

- So <propname> needs to compute which deltaV properties are defined for a
particular resource. This might *still* be an expensive operation, for
instance computing wether  <checked-in> or <checked-out> are present might
be as expensive as actually computing their values.

>    My example was referring back to your explanation about the true
>    usefulness of DAV:supported-live-property-set. Since I would like
>    to present all dead and standard properties (propfind/allprop),
>    plus know what type of resource I have got, I would need to get
>    DAV:supported-live-property-set as well (and hopefully _not_ more).
>
> OK I misunderstood (I thought you then wanted to actually retrieve all
> those properties as well) ... now that I understand what you actually
> are doing, I agree that it is very reasonable and sensible.
>
>    ... Maybe I need to supply a more specific example:
>    My code could be used by a WebFolder like application, which knows
>    about basic versioning. It would need to know for a collection
>    a) the "standard" RFC 2518 Properties, plus all dead properties (which
>       it might make use of internally)
>    b) if a resource is versionable (to allow context menu "make
>    versionable...")
>    c) if a resource is version-controlled, e.g. checked-in/out (to allow
>    context menu
>       entries like "check in..." etc.)
>    d) if a resource is versioned, e.g. part of history (to
> indicate that it
>    cannot be altered)
>
>    For this, it is useful to enhance PROPFIND/allprop to make only one
> request
>    against the WebDAV server. We did this in our implementation with good
>    results
>    like:
>
>    <D:propfind xmlns:D="DAV:">
>      <D:allprop/>
>      <ext:include xmlns:ext="http://greenbytes.de/ns/tests">
> 	<D:checked-in/>
> 	<D:checked-out/>
> 	<D:version-name/>
>      </ext:include>
>    </D:propfind>
>
>    This gives us good performance and also works against current
>    implementations of moddav, IIS 5.0 and SharePoint RC1.
>
> This all makes sense.  I agree that this is the best you can do
> with the current behavior of D:allprop.
>
> I support Stefan's proposal that we have a way of querying for
> all dead properties and a specified set of live properties. I
> believe we have a cleaner compatibility story if we introduce a
> new value (e.g. DAV:alldeadprop or DAV:all-dead-prop), and then
> allow that to be combined with a list of explicit properties, i.e.:
>
>    <D:propfind xmlns:D="DAV:">
>      <D:all-dead-prop/>
>      <D:checked-in/>
>      <D:checked-out/>
>      <D:version-name/>
>    </D:propfind>

I prefer Stefan's proposal because

a) it doesn't require a new "pseudo" property and

b) will interoperate with "old" RFC2518 based severs and clients well.


Julian

Received on Thursday, 24 May 2001 17:34:22 UTC