RE: PROPFIND instead of REPORT

I agree that the defn. for REPORT is fine.

I also agree with not restricting the definition of property more.  Server
implementors don't get the choice to add methods (vs properties) like we
do, we would need an alternative way for server implementors to marshal
"extra" live property information to the client, and I don't think that
additional implementation-specific reports are likely to work as well with
software that doesn't know about them in advance.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of
> Tim_Ellison@uk.ibm.com
> Sent: Tuesday, December 19, 2000 3:02 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: PROPFIND instead of REPORT
>
>
>
>
> 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.
>
> Regards,
>
> 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
> cc:
> 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
> property.
>
> 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.
>
> Comments?
>
> Cheers,
> Geoff
>
>
>
>
>
>

Received on Wednesday, 20 December 2000 13:38:46 UTC