Next message: Clemm, Geoff: "RE: Defaults"
Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D75A@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Thu, 9 Mar 2000 17:47:08 -0500
Subject: RE: Extending Target-Selector
My answer would be that the Revision-Selector header is just
a simplification for operations that involve exactly one versioned
resource. If you are doing an operation that
involves target selection for multiple resources, just don't
use the Revision-Selector header. Create an appropriate
revision-selection rule in a workspace, and just use the workspace
header.
Cheers,
Geoff
-----Original Message-----
From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com]
Sent: Thursday, March 09, 2000 12:53 PM
To: ietf-dav-versioning@w3.org
Subject: Re: Extending Target-Selector
I still maintain that it is strange to get a result back from a depth
infinity operation where the target selector was specified by both a
Workspace: and Revision-Selector: header.
The resulting URLs of the 'children' cannot be used as-is since there is no
combination of Workspace: and Revision-Selection: that will get you to the
same point.
For example,
PROPFIND depth infinty on /foo/bar, where foo is resolved in Workspace W1,
and bar is resolved by Revision-Selection: 'mylabel'.
If the answer comes back you have /foo/bar/cow -- what use is that? since
if I ask for /foo/bar/cow with workspace W1 and revision-selector 'mylabel'
now 'bar' is selected by the workspace and in general will be different to
the one selected by the 'mylabel'.
Tim
----------------
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: ietf-dav-versioning@w3.org ('Delta V')
Message-ID: <2000Mar01.160400.1250.1494398@otismtp.ott.oti.com>
Date: Wed, 01 Mar 2000 16:04:37 -0500
Subject: Extending Target-Selector
Do we expect depth infinity operations to return stable URLs or 'users'
URLs.
For example, PROPFIND depth infinity would be difficult to decode if the
URLs were all stable URLs--so I'll assume that they are user URLs in the
response.
Now if you extend Target-Selector to be:
All-But-Leaf-Selector: and
Leaf-Selector:
(we can argue about the names :-)
How do you interpret the results? Do the deep URLs conform to the same
All-But-Leaf-Selector: and Leaf-Selector: selection? That's confusing
since
the request-url used to have a leaf at the end, but in the deep operations
it's segments are all 'all-but-leaf' segments. If the dep URLs don't
conform tot he same selection criteria what do they conform to?
Tim