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
you
> 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
"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?

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.

Ok.

> > "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.

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.

Regards,
Tim
Received on Monday, 22 April 2002 11:18:48 GMT

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