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 Friday, 28 June 2002 18:23:04 UTC