> 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