Subject: RE: Status of PROPFIND allprop/include

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 21 Jun 2003 19:32:46 -0700

I started putting the allprop/include proposal into RFC2518bis.  THen I
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).  

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?

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.

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.  

Comments?

Lisa

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: Sunday, May 04, 2003 12:46 PM
> To: [email-masked]
> Cc: Jim Whitehead; Lisa Dusseault
> Subject: Status of PROPFIND allprop/include
> 
> 
> Jim, Lisa,
> 
> in
> 
 http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0073.html

I tried to summarize the consensus of the attendees at the interim meeting
regarding the allprop/include issue.

1) I'd like to confirm that this was the solution we agreed upon?

2) I'd like to gather feedback on how we proceed with this change. One
approach (a) would be that I update

http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-03.htm
l

with the new marshalling and let this be published as experimental RFC (the
drawback being that it uses elements in the DAV: namespace, thus should
really be a WG submission). Another approach (b) would be to start a new WG
document, and try to get it published as "proposed standard" ASAP.

What I really *don't* want to do is to wait for RFC2518bis, partly because
it's unclear when we'll be done with it, and also because at that point of
time we really should already have interoperable implementations of this.

Regards,

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 22 Jun 2003 11:50:42 +0200

Lisa,

> I started putting the allprop/include proposal into RFC2518bis.  THen I

Great!

> entire Multistatus response and parse it even when it contains useless

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).

> remembers what your bookmarks are) what client cares what the

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.

> information returned may be useless.

Yes, that's why ww decided to extend "prop" instead.

> find out the list of properties that exist that might or might not be

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 23 Jun 2003 09:03:39 -0400

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