From: jamsden@us.ibm.com To: ietf-dav-versioning@w3.org Message-ID: <852568A9.0069D5E4.00@d54mta03.raleigh.ibm.com> Date: Tue, 21 Mar 2000 14:15:55 -0500 Subject: Re: renaming "Workspace" header to be the "Target-Selector" header I like the workspace header whose value is a workspace resource. I never liked target... because it seemed to confuse the roles of revision selection and revision selection override. Workspaces select the revision while the revision-selector provides the override in those cases where it is necessary. So I guess I vote to leave them as is. |------------------------+------------------------> | | "Clemm, Geoff" | | | <gclemm@rational.com>| | | Sent by: | | | ietf-dav-versioning-r| | | equest@w3.org | | | | | | 03/21/2000 01:32 PM | | | | |------------------------+------------------------> >------------------------| | | | To: | | "DeltaV (E-mail)" | | <ietf-dav-versioning@| | w3.org> | | cc: | | Subject: | | renaming "Workspace" | | header to be the | | "Target-Selector" | | header | >------------------------| In my recent pass through the protocol, I've been finding it somewhat confusing to have both a workspace resource and a Workspace header. I'd like to try switching back to an earlier name, i.e. "Target-Selector" for this header to see if this makes things less confusing. I'd also like to change "Revision-Selector" to be "Request-Target-Selector" to emphasize its relationship to the "Target-Selector" header, and to emphasize that it only applies to target selection for the request URL. Another (very minor) advantage to this switch is that it would make it natural to put a workspace in both headers, so that you can copy from one working resource to another. For example, I could say: COPY /foo Request-Target-Selector: /workspaces/my_ws Destination: /foo Target-Selector: /workspaces/other_ws Any objections? Cheers, Geoff