RE: Replacing the Label header with a DAV:labeled-version report

Currently, the server can either silently ignore the properties
it cannot retrieve, or it can fail the entire report.

If you think it is important to allow a more fine-grained error
handling in this case, we could change the marshalling to be:

 <!ELEMENT labeled-version-report (response*)>

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email protected]]
Sent: Sunday, August 11, 2002 11:53 AM
To: Clemm, Geoff; 'Deltav WG'
Subject: RE: Replacing the Label header with a DAV:labeled-version
report


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: [email protected]
> [mailto:[email protected]]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:[email protected]]
> 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:[email protected]]
> 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:[email protected]]
> Sent: Saturday, April 27, 2002 5:09 AM
> To: Clemm, Geoff; 'Deltav WG'
> Subject: RE: Label header vs PROPFIND depth 1
>
>
> > From: [email protected]
> > [mailto:[email protected]]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:[email protected]]
> >
> >    - 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.
>
>