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

RE: Label header vs PROPFIND depth 1

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Mon, 22 Apr 2002 16:15:31 +0100
To: "Deltav WG" <ietf-dav-versioning@w3.org>
Message-ID: <OF9CC6A472.0EB1FF42-ON80256BA3.005350DC@portsmouth.uk.ibm.com>

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

The label: header causes the method to be applied to the version -- a
version is not a variant of a version-controlled resource, that is, a
version is not another representation of the version-controlled resource,
it is a whole new resource.

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

Well as you pointed out, we can define headers to have whatever semantics;
but consistency is good.

> 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
> > to whatever depth was requested"
> >
> > If the label: applied to each member of the version-controlled
> > 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*
> the member VCRs. You will not see the version URIs in the response body.

What do you mean by the _variants_ of a version-controlled resource?  My
understanding is that a variant is an alternate representation of a
resource, and that is not the case here.

Received on Monday, 22 April 2002 11:18:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC