W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2002

RE: Label header vs PROPFIND depth 1

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Mon, 22 Apr 2002 17:00:20 +0200
To: "Tim Ellison" <Tim_Ellison@uk.ibm.com>, "Deltav WG" <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEDMEHAA.julian.reschke@greenbytes.de>
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Tim Ellison
> Sent: Monday, April 22, 2002 4:51 PM
> To: Deltav WG
> Subject: RE: Label header vs PROPFIND depth 1
>
>
>
> "Julian Reschke" <julian.reschke@greenbytes.de> wrote:
>
> > > No, the label: header does not apply to the members of the
> > > collection, just
> > > the request-URI resource.  It behaves the same way as the
> Depth: header
> of
> > > RFC2518, i.e. Depth: 1 only applies to the method at the request-URI
> > > resource and not recursively to the members.
> >
> > Well, again I think that this is a major problem. It makes handling of
> the
> > "Label" header different from handling of other headers that selection
> > variants of a resource.
>
> How is it different to the Depth: header?  Ignoring the fact that Depth: 0
> and Depth: infinity degenerate into the 'right thing'.

The semantics of the depth header is explicitly defined for PROPFIND. So you
can think of it as a parameter to PROPFIND. Headers that select variants
simply are different.

> ..
>
> > So this is different from for instance handling of the "accept-language"
> > header. Can you give a reason why this would be desirable?
>
> Rather than decide whether it should be different from the handling of a
> "accept-*" header, we should agree on what is the most useful definition.

Well, it should also be consistent with the handling of other headers,
right?

> Unless you are suggesting that this difference makes it
> impossible/difficult to implement, and I don't think that it does.
>
> So, I think the reason it is the way it is, is so that the results of the
> depth operation conform to the definition of multistatus, i.e. that the
> results are related by collection membership.

They are -- keep in mind that *I* am discussing the case where the target
collection resource is *not* version-controlled.

> "the multistatus XML element for a collection resource with member URIs
> MUST include a response XML element for each member URI of the collection,
> to whatever depth was requested"
>
> If the label: applied to each member of the version-controlled collection,
> then the results would be a set of versions that were not related by
> membership.

No, the result isn't a set of versions anyway. It is a set of *variants* of
the member VCRs. You will not see the version URIs in the response body.
Received on Monday, 22 April 2002 11:00:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT