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

Received on Wednesday, 5 September 2001 09:24:44 UTC