Date: Tue, 30 May 2000 07:53:38 -0400 (EDT) Message-Id: <200005301153.HAA23580@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: 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