- From: Julian F. Reschke <julian.reschke@greenbytes.de>
- Date: Thu, 24 May 2001 23:34:00 +0200
- To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
> 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