Re: PROPFIND instead of REPORT (was Re: Minutes Delta-V breakout meeting 14-Dec-00)

I agree that its a strech to think of these things as properties, but one 
could consider Greg's example below to be the "synchronization properties" 
of some root directory. 

My issue is that we already have a number of ways produce reports: using 
servlets (or any other standard way of extending servers with custom 
reports), POST, PROPFIND, and now REPORT. My first suggestion was to use 
POST and just define the entity request body formats for interoperability. 
This didn't seem appealing. Next came PROPFIND. I think POST and PROPFIND 
are already existing, generic, extensible mechanisms while REPORT seems to 
be sort of a special case method. There's no difference in the semantics, 
just the marshalling, and POST and/or PROPFIND already provide sufficient 
semantics.

Greg, your example below could be done without any extension to WebDAV as 
your client can ask for the information it needs by doing PROPFINDs with 
depth on a collection.




I find that using PROPFIND rather than REPORT is a big bogus. I'm not
necessarily asking for properties. I'm asking for information from the
server. Is a compare-report a set of *properties* ?? Not in my mind.

For Subversion, I'm also going to be using a custom report. The client 
will
send to the server a representation of the client state. The server will
return a report saying something to the effect of, "that tree is out of
date; that file is an older version, but is equivalent to the latest; 
those
files are fine; etc"

That isn't a PROPFIND :-)

Cheers,
-g

On Mon, Dec 18, 2000 at 12:49:31AM -0500, Geoffrey M. Clemm wrote:
>
> At the recent IETF meeting, JimA proposed that we use PROPFIND instead
> of REPORT to obtain information from the server that requires
> arguments to qualify what kind of information is required.  Although
> an appealing thought, after mulling this over, I don't see how we
> could do this in a way that is compatible with PROPFIND but
> does not violate the property value DTD's.
>
> Jim's recent post describing a request of this kind doesn't really work:
>
> <?xml version="1.0" encoding="utf-8" ?>
>   <propfind xmlns="DAV:">
>     <prop>
>          <creator-displayname/>
>               <versions>show-last-five</D:versions>
>          <checkin-date/>
>              <versions>show-last-five</D:versions>
>     </prop>
>   </propfind>
>
> If you indent this consistently, it becomes:
>
> <?xml version="1.0" encoding="utf-8" ?>
>   <propfind xmlns="DAV:">
>     <prop>
>          <creator-displayname/>
>          <versions>show-last-five</D:versions>
>          <checkin-date/>
>          <versions>show-last-five</D:versions>
>     </prop>
>   </propfind>
>
> which seems to be a request for creator-displayname, checkin-date, and
> a repeated request for a property named "D:versions" (I'm assuming
> that all elements should have been prefixed by "D:").
>
> Based on his original indentation, JimA probably meant:
>
> <?xml version="1.0" encoding="utf-8" ?>
>   <D:propfind xmlns="DAV:">
>     <D:prop>
>          <D:creator-displayname>
>            <D:versions>show-last-five</D:versions>
>          </D:creator-displayname>
>          <D:checkin-date>
>            <D:versions>show-last-five</D:versions>
>          </D:checkin-date>
>     </D:prop>
>   </D:propfind>
>
> But now we've violated the DTD's for D:checkin-date and
> D:creator-displayname (which are supposed to be either empty or
> dates and strings, respectively, to display to the user).
>
> Currently, I think the avoidance of DTD ambiguity is worth
> the introduction of a new method (i.e. REPORT).
>
> Cheers,
> Geoff
>
>    From: "Lisa Dusseault" <lisa@xythos.com>
>    Date: Sun, 17 Dec 2000 16:33:44 -0800
>
>    I'm afraid I'm a little confused, perhaps it's just the indenting. Is
>    the <versions> tag supposed to be inside each the property name tags, 
or
>    parallel to them?
>
>    I'd suggest one only needs one <versions> tag per PROPFIND body, 
because
>    it's pretty nonsensical to ask for one property over 5 versions, and 
a
>    different property over 50 versions, all in one request. the client 
is
>    more likely to make separate requests.
>
>    Another suggestion is to reuse the "range" syntax and logic (e.g.
>    byte-range headers).  This allows a "last-n" selection, as well as "m
>    through n" or "first n".  Then we don't need to define custom syntax 
or
>    logic to pick which versions to show.
>
>    The basic idea, I think, is sound.
>
>    lisa
>
>    -----Original Message-----
>    From: ietf-dav-versioning-request@w3.org
>    [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden
>    Sent: Sunday, December 17, 2000 7:26 AM
>    To: ietf-dav-versioning@w3.org
>    Subject: RE: Minutes Delta-V breakout meeting 14-Dec-00
>
>
>    <lisa>
>    Hmm, this really argues for using PROPFIND since the client can say 
what
>    props they want for the version.  Perhaps instead of using attributes 
in
>    the
>    body of PROPFIND request (I never really understood where they would 
go)
>    there could just be an XML element to tell the server whether the 
client
>    wanted version detail or not:
>
>    PROPFIND thisresource
>
>    <?xml version="1.0" encoding="utf-8" ?>
>      <propfind xmlns="DAV:">
>        <versions>show-last-five</D:versions>
>        <prop>
>           <creator-displayname/>
>           <checkin-date/>
>        </prop>
>      </propfind>
>    </lisa>
>    <jra>Lisa, here's what we were planning:
>
>    <?xml version="1.0" encoding="utf-8" ?>
>      <propfind xmlns="DAV:">
>        <prop>
>           <creator-displayname/>
>                <versions>show-last-five</D:versions>
>           <checkin-date/>
>               <versions>show-last-five</D:versions>
>        </prop>
>      </propfind>
>
>    This is more compatible with 2518.
>

--
Greg Stein, http://www.lyra.org/