RE: PROPFIND allprop with more properties (was AW: Resource class )

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Friday, May 25, 2001 1:50 AM
> To: Julian F. Reschke; ietf-dav-versioning@w3.org
> Subject: RE: PROPFIND allprop with more properties (was AW: Resource
> class )
>
>
> > >
> > >    <D:propfind xmlns:D="DAV:">
> > >      <D:all-dead-prop/>
> > >      <D:checked-in/>
> > >      <D:checked-out/>
> > >      <D:version-name/>
> > >    </D:propfind>
> >
> > I prefer Stefan's proposal because
> >
> > a) it doesn't require a new "pseudo" property and
> >
> > b) will interoperate with "old" RFC2518 based severs and clients well.
> >
> It would NOT work with old implementations unless it looks like this:
>
> <D:propfind xmlns:D="DAV:">
>   <D:all-dead-prop/>
>   <D:prop>
>     <D:checked-in/>
>     <D:checked-out/>
>     <D:version-name/>
>   </D:prop>
> </D:propfind>

Could you explain?

Old servers will ignore the "include" element -- a new client will be aware
that is was ignored because the additionally selected properties will not
turn up anywhere in the multistatus response. An old client will never use
the "include" element, therefore there'll be no interoperatibility issues.

With your proposal, how would one get a) the RFC2518 standard properties +
b) dead properties + c) selected computed properties from DASL/ACL/... with
one PROPFIND?

> It's also not a solution to the problem unless we specifically deprecate
> allprop or change its meaning because naive and old clients will still do
> the expensive 'allprop'.  Especially because 'allprop' is the
> default for an
> empty PROPFIND request.

It wasn't meant to solve this problem -- it's a way for a client to
specifically request "almost all" properties + selected properties that
wouldn't show up otherwise.

Received on Friday, 25 May 2001 04:12:27 UTC