To: Greg Stein <gstein@lyra.org> cc: reuterj@ira.uka.de, jjh@ira.uka.de, ietf-dav-versioning@w3.org Date: Thu, 24 Aug 2000 20:58:01 +0200 From: Juergen Reuter <reuterj@ira.uka.de> Message-ID: <"iraun1.ira.0038201:000824.185805"@ira.uka.de> Subject: Re: Where have DAV:revision-set and DAV:working-resource-id/URL-set gone? > ... > Now, look at 14.1.1 and your concern will be answered. Version selectors > have a DAV:version-history property. That has a DAV:version-set property. > > DAV:working-resource-set on the version history resource satisfies your > other concern. Right! My "short look" at draft 07 was a little bit too short. DAV:version-set is exactly what I was looking for. I should not have expected it to occur as part of the core versioning. But then, DAV:version-tree-report is somewhat redundant, because you can get all information of a DAV:version-tree-report by examining DAV:version-set, if I understand right. Of course, while DAV:version-set is just a set and makes no assumptions about the order of the revisions, DAV:version-tree-report will report them in a terse form of a nested tree (which, however, is not unique). And, of course, as the core versioning part of the protocol must somehow provide access on the set of all revisions, dropping DAV:version-tree-report is no choice. I will have to think more deeply about this (and read 07 in more detail). > >... > > Section 3.5.1: > > ============== > > Mmh, the former DAV:predecessor-set had the advantage that I could use > > the same code for revisions and working resources when traversing through > > the revision tree including working resources as special leaves of the > > tree. But DAV:checked-out probably better reflects the concept of > > working resources. So I am not really sure what is better. > > What is the problem here? I don't understand the issue. Just a matter of style (clean spec design versus code reuse). Actually, I can live with both solutions. Thank you for your comments! Bye, Juergen