RE: Label header vs PROPFIND depth 1

> 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 UTC