Next message: jamsden@us.ibm.com: "Re: Defaults"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525689D.00743067.00@d54mta03.raleigh.ibm.com>
Date: Thu, 9 Mar 2000 16:08:59 -0500
Subject: Re: Extending Target-Selector
Tim,
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>|
| | Sent by: |
| | ietf-dav-versioning-r|
| | equest@w3.org |
| | |
| | 03/09/2000 12:52 PM |
| | |
|------------------------+------------------------>
>------------------------|
| |
| To: |
| ietf-dav-versioning@w|
| 3.org |
| cc: |
| 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