AW: Issue: ALLPROP_AND_COMPUTED

How about

a) looking again into the proposed PROPFIND extensions to get properties by
namespace (and to suppress specific namespaces), and

b) put for example the deltaV properties into a different namespace?

Julian

> -----Ursprungliche Nachricht-----
> Von: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Greg Stein
> Gesendet: Freitag, 4. Mai 2001 07:59
> An: w3c-dist-auth@w3.org
> Betreff: Re: Issue: ALLPROP_AND_COMPUTED
>
>
> On Wed, May 02, 2001 at 11:53:27PM -0400, Clemm, Geoff wrote:
> > I am adamantly opposed to DAV:allprop.  In the context of
> > computed live properties, a client should never blindly ask
> > for all property values ... it should always first ask for
> > DAV:propname, and then use the subset that it can use.
>
> Euh, how does the propname help the computed live prop case? If I
> fetch all
> the names, then fetch the values, then I've still slammed the
> server with a
> bunch of computed props.
>
> Removing allprop does not help this scenario at all.
>
> > The WebDAV versioning extensions explicitly allows a server to
> > *not* return the versioning properties in response to a
> > DAV:allprop request, so DAV:propname will be the only reliable
> > way of obtaining all the properties.
>
> When did that go in? That seems to be a direct violation of RFC 2518.
>
> > Finally, the fact that
> > PROPFIND/DAV:allprop is trivially replaceable with two PROPFIND
> > calls (the first being PROPFIND/DAV:propname) makes DAV:allprop
> > superfluous (in addition to being inadvisable).
>
> It is *NOT* trivial. If you want to do a Depth:1, then the client is going
> to have to create a union of all the resources' prop names, then do the
> fetch for those props. Next, it will need to deal with the 404
> that it will
> get for the props that weren't available on all resources.
>
> Trivial? Bah.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>

Received on Friday, 4 May 2001 02:22:37 UTC