RE: REPORTS

Hi,

I believe that when the issue of moving the expand property report
was raised at the IETF meeting someone (Lisa I think) had a good use 
case where the client had a need for this report.
It was that use case that drove us to decide that the report is
actually very useful and that we should recommend that server
vendors implement it.

That use case was not captured in the minutes, anyone remember
what the scenario was?

Regards,
--
Peter Raymond - MERANT
Technical Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com



-----Original Message-----
From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com]
Sent: 05 September 2001 14:23
To: 'DeltaV'
Subject: Re: REPORTS


"John Hall" <johnhall@evergo.net> wrote:

> I've been on vacation, but I've tried to keep up.
>
> In version #17 the expand-property report has been
> moved from an optional report (Section 15 of
> version #16) to a SHOULD implement in 3.8.
>
> I object to it being listed there, and I recall no
> discussion let alone a consensus to moving it from
> section 15.  Outlook does not find 'expand-property'
> listed in any discussion of this type in my folder
> dedicated to DeltaV messages.  As an optional report,
> I did not pay any attention to it.  The nesting
> feature (properties within properties) makes this a
> very difficult and annoying feature to implement or
> use IMHO.

This was discussed in the ondon IETF meeting and reported in the minutes
http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001JulSep/0193.html


As I recall, there was little objection in the room to this report as it
was considered a relatively simple recursion for the client and/or server
to implement.

> ====================
>
> The version-tree report also seems to be defined
> differently (in 16 as well as 17) than I thought.  I
> can implement it that way (fix my implementation), but
> it seems more limited that it should be.
>
> For example, I see no reason to redirect a version-tree
> report to the checked-out version of a VCR.  It makes
> more sense to print the following information, if the target
> is a VCR:
>
> 1. A listing for the VCR (properties can be different
> than for a version)
> Followed by a listing for each version in the VCR (starting
> with the latest version and continuing on down).

Not sure what you mean here.  The 'redirect' to the version is simply a
convenience.  What do you mean by "each version in the VCR"?  The report
will be applied to all versions in the version history of a version.

> As currently defined, it takes 2 calls to get all the
> properties you want on all the versions of a file.

No, the properties will be returned for all versions on a single REPORT
request.

> One to pick up any properties on the VCR including the
> location of the VHR and the other to pick up additional
> properties on the file versions.

The version tree report reports properties on versions.  You would simply
use PROPFIND to get the properties for a version-controlled resource.  Of
course, you could use the expand property report to get properties for a
version-controlled resource and its checked-in/-out version and/or version
history.

> Acutally, I'd far prefer the following definition for
> version 3.7:
>
> The DAV:version-tree report describes the requested
> properties of all the versions in the version history
> of a version.  If the report is requested for a
> version-controlled resource, then the requested properties
> of the version-controlled resource are supplied in addition
> to the requested properties for all the versions in the
> version history of the version.

I have no strong objection to tis, but would like to see the `compelling
use case' that warrants a change.

> A server MAY support a depth value other than 0.  If so,
> the report may target a collection and the report is
> applied to each versioned controlled resource in the tree.

This is already covered in the postcondition for REPORT, right?

Regards,
Tim