Next message: Tim Ellison/OTT/OTI: "Re: If: header and "parent" resource checking"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568EF.004B8A23.00@d54mta02.raleigh.ibm.com>
Date: Tue, 30 May 2000 09:45:05 -0400
Subject: Re: Why do we need working resource ids ?
I think we need to keep uniformity between working resources and revisions.
When a working resource is checked out, the request-URL will be for the
versioned resource, and the Target-Selector will select the revision to
check out. (Note that I think Target-Selector should take a workspace,
label, revision id, etc.). The return value from checkout needs to be
something that can be applied in the Target-Selector along with the
versioned resource URL (the same one used on checkout) for subsequent
requests. This should be the working resource id. Alternatively, if the
client knows the working resource stable URL, that can be used as the
request-URL ignoring the Target-Selector header to access the same
resource. This is the same as for revision selection.
From: Edgar@EdgarSchwarz.de
a CHECKOUT returns a working resource id. Wouldn't it be possible
to drop that ? Normally a CHECKOUT works in the context of a
workspace (explicit or implicit). So I expect a server to give me
the working resource if I later GET and specify versioned resource
and workspace.
I believe Edgar makes an excellent point here. Until recently, our
answer would have been "because a server does not allocate a URL for
each working resource, and so a working resource id is required for
those working resources without their own URL's". But if we take the
design teams recommendation from last week and require that a server
provide a working resource URL for every working resource, then
working resource id's are no longer needed. I think this
significantly simplifies the protocol, so I vote to accept Edgar's
suggestion. We then just need an optional argument to the CHECKOUT
routine that tells the server to allocate a new URL for the working
resource (by default, the server would just use the request URL, just
as is done in a workspace context). In any case, the URL for the
working resource created by the CHECKOUT routine would be returned in
the Location response header.
BTW, the introduction to workspaces in 7.1 is too technical IMHO.
It should describe what we want to achieve with it. E.g. that it
is a filter or view which can help authors to coordinate their work.
Also I think a workspace server shouldn't define a 'request workspace',
but a 'user workspace' if no workspace header is given for a request.
I believe that this concern is addressed by the proposal to model a
workspace as just a special kind of collection. I'll try to get something
written up this week -- please let me know if the new description
provides a simpler model for workspaces (I believe it does).
Cheers,
Geoff