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

Juergen,

Your conclusions are correct, however, the earlier observations remain --
that this level of change to RFC2518 is unlikely to occur given the
momentum it has achieved.  We should focus on backwards compatible
extensions.

Regards,

Tim


Juergen Reuter <reuterj@ira.uka.de> on 2000-12-18 11:14:33 AM

Please respond to Juergen Reuter <reuterj@ira.uka.de>

To:   "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc:   reuterj@ira.uka.de, jjh@ira.uka.de, ietf-dav-versioning@w3.org
Subject:  Re: PROPFIND instead of REPORT           (was Re: Minutes Delta-V
      breakout meeting 14-Dec-00)




> <?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
http://lists.w3.org/Archives/Public/ietf-dav-versioning/2000OctDec/0244.html
).

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

<?xml version="1.0" encoding="utf-8" ?>
  <D:propfind xmlns="DAV:">
    <D:prop>
      <D:property-name>creator-displayname</D:property-name>
      <D:property-versions>show-last-five</D:property-versions>
      <D:property-name>checkin-date</D:property-name>
      <D:property-versions>show-last-five</D:property-versions>
    </D:prop>
  </D:propfind>

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
workaround?

Bye,
     Juergen

Received on Monday, 18 December 2000 07:50:03 UTC