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

> What is the *benefit* of this special handling?

See below.

> > > Yes. But if the collection isn't versioned (does not vary on the
Label
> > > header), the Label header just should be *ignored* (for the
collection),
> > and
> > > then *apply* to the indivual versioned members of the collection.
> >
> > No, it will be ignored for the target of the method, and ignored for
the
> > members of the collection.
>
> 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.
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.

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

Regards,
Tim

Received on Monday, 22 April 2002 10:51:03 UTC