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

   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   one concern, almost the same as with the old approach (PROPFIND
   with label header):

   Which hrefs should be reported? I think the href property should be
   the URI of the version, not the one of the VCR or the VHR.

As indicated in the DAV:labeled-version example, the URI is the
one of the VCR (just like a Depth PROPFIND).  But see the answer
to your next question.

   Also: what is the DAV:version property that appears in the example?

I should have mentioned that I resurrected the old DAV:version
property to make the DAV:labeled-version report work cleanly.
The DAV:version property only appears on version resources,
and contains the server-defined URL for that version.

So the DAV:labeled-version report always reports the VCR URL,
but can also report the version URL (and/or the version history URL)
if requested to do so by the client (i.e. specifies
DAV:version and/or DAV:version-history in the DAV:prop request
element.

Does this address your concern?

Cheers,
Geoff

   > -----Original Message-----
   > From: ietf-dav-versioning-request@w3.org
   > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
   > Sent: Friday, June 28, 2002 9: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:creator-displayname>Fred</D:creator-displayname>
   >           <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>
   >
   > -----------------------------------------
   >
   > Cheers,
   > Geoff
   >
   > -----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 Friday, 28 June 2002 17:01:17 UTC