W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

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

From: Juergen Reuter <reuterj@ira.uka.de>
Date: Mon, 18 Dec 2000 12:14:33 +0100
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: reuterj@ira.uka.de, jjh@ira.uka.de, ietf-dav-versioning@w3.org
Message-ID: <"iraun1.ira.0096901:001218.111203"@ira.uka.de>
> <?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).

This is just another nice example for a problem that can elegantly be
solved with the DTD change for properties that James and I recently
suggested (see

With this change, you could think of something like the following:

<?xml version="1.0" encoding="utf-8" ?>
  <D:propfind xmlns="DAV:">

Instead of requiring that a DAV:property-versions element follows each
DAV:property-name element, one could -- following Lisa's suggestion --
define the DTD to allow only one DAV:property-versions element as the
last (or, alternatively, the first) element within the DAV:prop
element.  Or, if you like overkill, write a DTD that either allows a
single DAV:property-versions element as the first element within a
DAV:prop element or a DAV:property-versions element after each
D:property-name element.

BTW., the "show-last-five" is subject to be replaced by something
seriously specified, right?

> Currently, I think the avoidance of DTD ambiguity is worth
> the introduction of a new method (i.e. REPORT).

If RFC2518 had introduced a D:property-name as in the above example, the
new D:property-versions element just could be ignored by servers that do
not know this element without breaking compatibility.  Maybe it is really
time to fix this in RFC2518 rather than introducing yet another

Received on Monday, 18 December 2000 06:12:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC