RE: Status of PROPFIND allprop/include

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

Received on Sunday, 22 June 2003 05:51:29 UTC