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


From: <Tim_Ellison@uk.ibm.com>
Date: Tue, 19 Dec 2000 11:01:56 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569BA.003C9A8C.00@d06mta07.portsmouth.uk.ibm.com>

This is an honourable proposal, but I believe that it would be too
restrictive to apply that definition of 'property'.

As you mention, it would require that we redefine some existing versioning
properties (DAV:successor-set, DAV:checkout-set,
DAV:baselined-collection-set) which I think is unfortunate since they are
currently useable by (and useful to) versioning aware DAV level 1 clients.

In addition, it would place unfortunate restrictions upon custom live
properties defined by servers.

The definition for REPORT is fine.


Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK.
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452

"Clemm, Geoff" <gclemm@rational.com> on 2000-12-18 03:21:45 PM

Please respond to "Clemm, Geoff" <gclemm@rational.com>

To:   ietf-dav-versioning@w3.org
Subject:  RE: PROPFIND instead of REPORT (was Re: Minutes Delta-V breakout
          meeting  14-Dec-00)

Currently, a REPORT is defined as "a request for information that
requires more than one argument and does not modify the visible state
of any resource on the server".

I'd like to propose a new criteria for differentiating a property
(what you get with PROPFIND) from a report (what you get with REPORT):


A "property" is information about a resource that can only be updated
by applying a request to that resource.

A "report" is a request for information that does not modify the
visible state of any resource on the server.


One advantage of these criteria is that they provide concrete value to
a client implementation.  In particular, a client knows that when it
applies a method to a resource, the only properties it needs to
re-fetch (to reflect the result of that method) are the properties of
the resource itself.

Another advantage of these criteria is that they are consistent with
the currently standardized live properties (so they don't "break"
existing implementations).

A more subjective advantage of these definitions is that I believe
they correspond to many people's intuition about what is a property
and what is a report. In particular, a "dead property" is clearly a

If we use these criteria, a few of the current versioning "properties"
would need to become reports (e.g. DAV:successor-set,
DAV:checkout-set, DAV:baselined-collection-set).  This actually would
simplify the protocol, since we no longer would need the
post-conditions on MOVE and DELETE that say these properties
are updated when a resource they contain is moved or deleted.


Received on Tuesday, 19 December 2000 06:03:31 UTC

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