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

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.

Received on Monday, 18 December 2000 00:50:20 UTC