- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Sun, 11 Aug 2002 17:52:35 +0200
- To: "Clemm, Geoff" <gclemm@rational.com>, "'Deltav WG'" <ietf-dav-versioning@w3.org>
Geoff, with the currently proposed format, how does a server marshall information about failures in retrieving the properties of the selected version (à la DAV:propstat/DSAV:status in DAV:response)? Julian > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Saturday, June 29, 2002 12:23 AM > To: 'Deltav WG' > Subject: RE: Replacing the Label header with a DAV:labeled-version > report > > > > Julian didn't like the marshalling of this report, > because it makes it look like the properties are those of > the VCR, when they actually are properties of the version > (Basically, I was just being lazy and re-using the D:response > element in a bogus fashion). > > So how about the following instead: > > ----------------------------------------------- > > 8.3 DAV:labeled-version Report > > The DAV:labeled-version report describes the requested > properties of the version with that label in a specified > version history. If the DAV:labeled-version report is > applied to a version-controlled resource, it is applied > to the DAV:version-history of that version-controlled resource. > > Marshalling: > > The request body MUST be a DAV:labeled-version XML element. > <!ELEMENT labeled-version ANY> > ANY value: a sequence of zero or more elements, with at most > one DAV:prop element and with exactly one DAV:label-name element. > prop: see RFC 2518, Section 12.11 > > The response body for a successful Depth:0 request MUST be > a DAV:labeled-version-report XML element. > > <!ELEMENT labeled-version-report (href, prop)> > prop: see RFC 2518, Section 12.11 > > The DAV:href identifies the selected version, and the DAV:prop > contains the requested properties of that version. > > 8.3.1 Example - DAV:labeled-version Report > >>REQUEST > > REPORT /folder/ HTTP/1.1 > Host: www.webdav.org > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > Depth: 1 > > <?xml version="1.0" encoding="utf-8" ?> > <D:labeled-version xmlns:D="DAV:"> > <D:label-name>tested</D:label-name> > <D:prop> > <D:version-name/> > </D:prop> > </D:labeled-version> > > >>RESPONSE > > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > > <?xml version="1.0" encoding="utf-8" ?> > <D:multistatus xmlns:D="DAV:"> > <D:response> > <D:href>http://www.webdav.org/folder/</D:href> > <D:propstat> > <D:prop> <D:labeled-version-report> > <D:href>http://repo.webdav.org/his/23/ver/V5</D:href> > <D:prop> > <D:version-name>V5</D:version-name> > </D:prop> > </D:labeled-version-report> </D:prop> > <D:status>HTTP/1.1 200 OK</D:status> > </D:propstat> > </D:response> > <D:response> > <D:href>http://www.webdav.org/folder/foo.html</D:href> > <D:propstat> > <D:prop> <D:labeled-version-report> > <D:href>http://repo.webdav.org/his/84/ver/V8</D:href> > <D:prop> > <D:version-name>V8</D:version-name> > </D:prop> > </D:labeled-version-report> </D:prop> > <D:status>HTTP/1.1 200 OK</D:status> > </D:propstat> > </D:response> > </D:multistatus> > > > ----------------------------------------- > > > Cheers, > Geoff > > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > Sent: Friday, June 28, 2002 3:18 PM > To: 'Deltav WG' > Subject: RE: Replacing the Label header with a DAV:labeled-version > report > > > > So far, everyone has either agreed or remained silent on this topic, > so as a motivator for anyone objecting to speak up (:-), I will mark this > issue > as resolved in the errata, with the resolution being that the Label > header will be deprecated, and the DAV:labeled-version REPORT inserted > in its place. In particular, I propose the following definition for > the DAV:labeled-version REPORT: > > ------------------- > > 8.3 DAV:labeled-version Report > The DAV:labeled-version report describes the requested properties > of the version with that label in a specified version history. > If the DAV:labeled-version report is applied to a version-controlled > resource, it is applied to the DAV:version-history of that > version-controlled resource. > > Marshalling: > > The request body MUST be a DAV:labeled-version XML element. > > <!ELEMENT labeled-version ANY> > > ANY value: a sequence of zero or more elements, with > at most one DAV:prop element and with exactly one > DAV:label-name element. > > prop: see RFC 2518, Section 12.11 > > The response body for a successful request MUST be a DAV:multistatus > XML element. > > multistatus: see RFC 2518, Section 12.9 > > The response body for a successful DAV:labeled-version REPORT > request MUST contain a DAV:response element for each resource > that satisfies the Depth header of the request. > > 8.3.1 Example - DAV:labeled-version Report > > >>REQUEST > > REPORT /folder/ HTTP/1.1 > Host: www.webdav.org > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > Depth: 1 > > <?xml version="1.0" encoding="utf-8" ?> > <D:labeled-version xmlns:D="DAV:"> > <D:label-name>tested</D:label-name> > <D:prop> > <D:version-name/> > <D:version/> > </D:prop> > </D:labeled-version> > > >>RESPONSE > > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > > <?xml version="1.0" encoding="utf-8" ?> > <D:multistatus xmlns:D="DAV:"> > <D:response> > <D:href>http://www.webdav.org/folder/</D:href> > <D:propstat> > <D:prop> > <D:version-name>V5</D:version-name> > <D:version> > <D:href>http://repo.webdav.org/his/23/ver/V5</D:href> > </D:version> > </D:prop> > <D:status>HTTP/1.1 200 OK</D:status> > </D:propstat> > </D:response> > <D:response> > <D:href>http://www.webdav.org/folder/foo.html</D:href> > <D:propstat> > <D:prop> > <D:version-name>V8</D:version-name> > <D:version> > <D:href>http://repo.webdav.org/his/84/ver/V8</D:href> > </D:version> > </D:prop> > <D:status>HTTP/1.1 200 OK</D:status> > </D:propstat> > </D:response> > </D:multistatus> > > ----------------------------------------- > > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > Sent: Sunday, April 28, 2002 9:53 AM > To: 'Deltav WG' > Subject: Replacing the Label header with a DAV:labeled-version report > > > Since this is a fairly significant change, I'd like to > hear from a few more folks before adding this to the 3253 Errata. > > Thanks, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@greenbytes.de] > Sent: Saturday, April 27, 2002 5:09 AM > To: Clemm, Geoff; 'Deltav WG' > Subject: RE: Label header vs PROPFIND depth 1 > > > > From: ietf-dav-versioning-request@w3.org > > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Friday, April 26, 2002 6:06 PM > > To: 'Deltav WG' > > Subject: RE: Label header vs PROPFIND depth 1 > > > > > > From: Julian Reschke [mailto:julian.reschke@greenbytes.de] > > > > - I'd like to see the label *header* deprecated > > - I'm happy with the LABEL method and the label-name-set property > > - I think that PROPFIND/label should be replaced by a specific REPORT > > > > Is the proposed DAV:labeled-version report OK with you? > > Yes. But I think it's Tim's turn to say whether this would work for him or > not... > > > - I'm unsure about other methods that are currently affected by the > > header -- what were the requirements...? > > > > The other methods are LABEL, CHECKOUT, GET, and COPY. > > For Depth:0 variants of these operations, the Label header > > just provided an optimization to save one roundtrip > > (i.e. first getting the version URL via the DAV:labeled-version report). > > I believe we can easily do without that Depth:0 optimization. > > As stated before, I think that's not the single problem. Having > GET return a > (representation of a) version rather than (a representation of) the VCR > makes the version *by definition* a variant (representation) of the VCR -- > and it seems that most of us want to avoid that interpretation. > > > For Depth:infinity (only relevant for LABEL and COPY), the savings > > would be more significant, but unfortunately the semantics is broken > > (since if the namespace is being versioned, you'll get the wrong > > resources if you simply do a Depth operation on the current namespace). > > > > The Depth:infinity Label header operations are really just a way of > > trying to have the client fake workspaces and baselines, instead of > > having the server support them directly. Since it is much more > > efficient and reliable to have the server layer these constructs > > above a labeling infrastructure, rather than having the client do > > so, I believe the cost of maintaining these Depth:infinity Label > > header operations in the protocol is not warranted. > > > > Note though that (depth:0) labeling and baselining go very well > > together. Instead of doing a Depth:infinity LABEL, you can create a > > baseline (which under the hood the server may well implement with > > reserved labels, but maybe not), and then LABEL that baseline. Then > > when you want to do a Depth:infinity COPY, you retrieve the > > DAV:baseline-collection of the labeled baseline (using the > > DAV:labeled-version report), and copy that to wherever you want. > > > > Alternatively, if you want a "modifiable" selection, you can create a > > workspace (which under the hood the server may well implement with > > reserved labels, but maybe not). When you want to adjust the versions > > being selected, you just use UPDATE. Then when you want to do a > > Depth:infinity COPY, you just copy from that workspace to wherever you > > want. > > > > - Servers that decide to implement LABEL and DAV:label-name-set, > > but no not support the label header should *not* report the LABEL > > feature in OPTIONS. > > > > That's probably right. A client can find out if the LABEL operation > > is supported by querying the DAV:supported-method-set property values > > of a VCR. > > ...and also use DAV:supported-live-property-set to discover the > DAV:label-name-set property. > >
Received on Sunday, 11 August 2002 11:52:43 UTC