Next message: Clemm, Geoff: "RE: Extending Target-Selector"
Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D759@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Thu, 9 Mar 2000 17:43:18 -0500
Subject: RE: Extending Target-Selector
If the PROPFIND user wants to know which revision of a resource
they got, they can just make sure their PROPFIND request includes
a request for the DAV:revision property.
I'm not sure what you meant by "all returned entity response bodies".
Each request has a single entity response body, and in the case of
methods like GET, you can't stuff additional XML elements into them.
Cheers,
Geoff
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Good catch. I think the solution must be to extend the DAV:link and href
elements in all returned entity response bodies to include the revision
selected. This is part of the identifier for the resource and must be
included. The effect on other WebDAV methods must include this issue.
|------------------------+------------------------>
| | Tim Ellison/OTT/OTI |
| | <Tim_Ellison@oti.com>|
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