RE: semantics of PROPFIND

1. The general rule with depth is that unless specifically instructed
otherwise you can always just "slap" it on. Think of the definition as "If
there are children, involve them to this specified level." So if you are
copying a single file and put a depth: infinity on it, nothing bad will
happen. After all, all 0 children have been copied. Do note, however, that
certain methods restrict the use of depth and the values that may be
submitted. This is for compatibility purposes. Programs need to know which
values of depth they can rely upon a method supporting. So, for example,
many methods support 0 and infinity while say, PROPFIND, supports 0, 1, and
infinity.

2. I will update the spec to specify that the HREF must ALWAYS be included.

2. Agreed.

3. I don't understand this comment. Could you please point out the example
you are referring to?

		Yaron

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	Tuesday, January 06, 1998 5:44 PM
> To:	w3c-dist-auth@w3.org
> Subject:	semantics of PROPFIND
> 
> 1. For a PROPFIND on a resource that is not a collection, what are the
> semantics of Depth that is not 0? Is it an error?  Is it ignored? Is it
> left undefined?
> 
> 2. When Depth is 0, is a server allowed to return an href property in
> response, or is it forbidden?  The example in the spec shows no href, but
> the spec should say explicitly whether one is allowed.  I say it should be
> either optional or mandatory, but not forbidden.
> 
> Now two suggestions/reminders for the writeup:
> 
> 1. Judith Slein asked:
> > 2.  What will PROPFIND behavior be if I ask for, say, the author
> property
> > and the title property, and some of the members of the collection have
> > those properties while others do not?  What I want to happen if I'm
> using
> > PROPFIND as a substitute for INDEX is that I get at least the href for
> > every member of the collection, whether or not it has the properties I
> > requested.
> 
> And Yaron said he'd put in language to make explicit that one DOES get a
> result for every member.
> 
> 2. The spec should say *explicitly* that the results of PROPFIND (for
> non-zero Depth) are a flat list that there is no indication of containment
> except by examining the URIs in the HREFs.  It should also state that
> there
> is no significance to order (at least, until we agree to adopt ordered
> collections :-))
> 
> 3. The spec should say, explicitly, that when there is more than one
> status
> result for a given URI, there will be separate instances of response for
> each status.  I know this is implied by the examples, but in general, a
> specification should not depend upon examples to be complete.
> 
> 
> best regards
> 
> Jim
>

Received on Wednesday, 7 January 1998 13:56:58 UTC