RE: Status of PROPFIND allprop/include

I assume that dead-props should be followed by a "?", not a "+", i.e.:

 <!ELEMENT propfind (allprop | propname | (prop, dead-props?)) >
 <!ELEMENT dead-props EMPTY >

Otherwise, this is fine with me.

Cheers,
Geoff

Julian wrote on 06/22/2003 05:50:42 AM:

> 
> Lisa,
> 
> > I started putting the allprop/include proposal into RFC2518bis.  THen 
I
> 
> Great!
> 
> > realized that in some of our discussions, we've leaned towards 
deprecating
> > 'allprop' entirely in favour of 'propname' to help server performance 
(and
> > client performance, at least in so far as client must still download 
the
> > entire Multistatus response and parse it even when it contains useless
> > info).
> 
> Yes, we did. We also discussed this in January during the Interim 
meeting,
> and therefore changed the syntax. Don't you remember? (I think by 
accident
> you've been looking at the original proposal rather the updated one).
> 
> > How often do clients really want all the *values* of all dead
> > properties?  I
> > understand readily how clients want to see a list of the names of all 
dead
> > properties.  But if I've added a dead property to my home
> > directory which is
> > called "sharefromstestuser_x0040_1_x003a_1501" in the namespace
> > "http://www.xythos.com/namespaces/StorageServer"  (this is how 
Sharemation
> > remembers what your bookmarks are) what client cares what the
> > value of that
> > dead property is?
> 
> The client sometimes can be a library or a proxy/gateway that simply has 
no
> knowledge about what *it's* client will be interested in. Consider an 
API
> that offers access to dead properties of a remote resource. It will 
perform
> much better if it's able to simply get *all* properties in one request.
> 
> > Next question, what's the harm?  Well, it takes time to look up all 
the
> > values of dead properties, escape them or encapsulate them,
> > marshal them in
> > XML and send them down the wire.
> >
> > So the risk of making 'allprop' more useful through an 'include' 
syntax is
> > that it makes 'allprop' more likely to be used even though much of the
> > information returned may be useless.
> 
> Yes, that's why ww decided to extend "prop" instead.
> 
> > I think it might be even more useful and efficient to combine the
> > 'propname'
> > syntax with the specific list of all the properties the client
> > really wants
> > the values for.  E.g.
> >
> > PROPFIND blah
> > Host: foo.bar
> > Content-Type: text/xml
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:propfind xmlns:D="DAV:">
> >    <D:propname/>
> >    <D:prop xmlns:R="http://www.example.com/boxschema/">
> >       <R:bigbox/>
> >       <R:author/>
> >       <R:DingALing/>
> >       <R:Random/>
> >    </D:prop>
> > </D:propfind>
> >
> > Now the client gets the property values that will truely be useful, 
plus
> > find out the list of properties that exist that might or might not be
> > useful.
> 
> 1) This breaks RFC2518 servers (prop and propname are not allowed at the
> same time) and
> 
> 2) the client still will need to requests where before one was enough.
> 
> 
> So again, here's what we dicussed in January and agreed upon:
> 
> 
> ---
> 
> during the WG meeting, we briefly discussed our allprop/include proposal
> (see [1] for latest draft). Among the attendees (:-)), there was 
consensus
> that a feature like this is useful and should be incorporated into
> RFC2518bis.
> 
> A slight change was applied to the syntax -- instead of using 
DAV:allprop
> with a specific include extension, the logic was reversed, such as:
> 
> <propfind xmlns="DAV:">
>   <prop>
>      ... named properties...
>   </prop>
>   <dead-props />
> </propfind>
> 
> The updated DTD for propfind thus would be:
> 
> <!ELEMENT propfind (allprop | propname | (prop, dead-props+)) >
> <!ELEMENT dead-props EMPTY >
> 
> (one advantage being that we're not extending DAV:allprop which is 
already
> increasingly misnamed).
> 
> ---
> 
> (see
> 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0073.html>).
> 
> BTW: in the meantime I updated my original proposal with an appendix
> describing January's agreement:
> 
> 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-lates
> t.html#rfc.section.A>
> 
> Regards, Julian
> 
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>