From: Tim_Ellison@uk.ibm.com
When a Workspace header is included in a request, the internal
members of that workspace are treated by that request as if they were
internal members of "/".
<tim> yes, '...by that request...' no mention of the response <g>
Well, since the request generates the response, I'd think that it
would necessarily follow (:-), but I'll add some words that explicitly
state this.
This means that all URL's generated in the responses must act that
way as well (i.e. act as if the way to get to members of the collection
is by going through "/").
<tim> This would be the natural assumption, but what about the URLs to,
say, working resources that cannot be expressed relative to a workspace.
This is certainly an issue with a Workspace header. One approach is
to put those workspaces on a different (possibly virtual) host.
Another approach is to put a binding to those resources in every
workspace (probably the approach our implementation will use).
As a side note, if you are supporting workspaces, you commonly
will be checking out the version selectors, not versions, so
working resources would not be an issue.
<tim> In any case, I think it would be polite if the server mentioned the
workspace URL it was using in its response.
That's fine with me. I'll add it in, since I don't think anyone will
object (we can always take it back out, if someone comes up with a
good objection).
Cheers,
Geoff