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

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

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 22 May 2001 16:58:47 +0200
To: <ietf-dav-versioning@w3.org>
Message-ID: <NDBBKJABLJNMLJELONBKOEKHCNAA.stefan.eissing@greenbytes.de>

> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Clemm, Geoff
> Gesendet: Dienstag, 22. Mai 2001 16:24
>    From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>    ... I found that the versioning properties did
>    vanish from PROPFIND/allprop in revision 14.1 of the draft.
>    With the current state of things, I'd have to do 2 PROPFINDS (one
>    allprop to catch all dead properties, one specific DAV:supported*
>    to know about versioning and resource status).
> Versioning properties are included in PROPFIND/DAV:propname, so you do

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?

> need two requests, but they would be a PROPFIND/DAV:propname request,
> and then a PROPFIND on the list of properties returned by the
> PROPFIND/DAV:propname.

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).

> But I would think hard about ever having an application blindly ask
> for all the properties on a set of resources.  These properties could
> be very expensive to compute, and since you have no way of determining
> how long these property values are valid, caching them is of
> questionable value.

I totally agree.

>    Has it been discussed already (could not find it in the archive) to
>    enhance allprop by allowing the client to specify additional
> properties?
>    This would make the body of a PROPFIND look like
>    <propfind xmlns="DAV:">
>      <allprop>
>      <prop>
>        <supported-method-set/>
>        <supported-live-property-set/>
>      </prop>
>    </propfind>
>    and the result would be the joined set of a PROPFIND/allprop
>    and PROPFIND/prop.
>    (The only related thing I could find was the "WebDAV PROPFIND
>    Extension To List Specified Namespaces" Draft from August 1999.
>    Which is a nice draft, but I assume it is too late to move the
>    versioning props into a separate namespace...)
> Because of the issues mentioned above (i.e. expense of computing live
> property values, and the absence of support for reliable property
> value caching), the versioning protocol does not worry about the extra
> round required to obtain "all versioning properties".  A live property
> is effectively a "query" on the state of a resource.  Would one
> expect to be able to "perform all known queries on this resource"
> in a single round trip?

Certainly not. 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
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

<D:propfind xmlns:D="DAV:">
  <ext:include xmlns:ext="http://greenbytes.de/ns/tests">

This gives us good performance and also works against current
of moddav, IIS 5.0 and SharePoint RC1.

Regards, Stefan
Received on Tuesday, 22 May 2001 10:59:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC