Next message: Geoffrey M. Clemm: "Re: Workspaces as versionable resources"
Date: Tue, 30 May 2000 12:10:40 -0400 (EDT)
Message-Id: <200005301610.MAA23882@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Why do we need working resource ids ?
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
I agree. Now that we have working resource URLs, let's drop the working
resource id.
Did I hear you say revision id as well ?<g>
Well, why not? If you have a server-generated URL that identifies
a revision, why have a separate server-generated id that identifies
that revision as well?
If a server wishes to automatically generate a short label
(e.g. "1", "2", "2.1") that a user can use in a Target-Selector,
then it can do so, but I see no reason to require it in the
protocol (we can't standardize the form of that id in any case).
Cheers,
Geoff
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
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