RE: Feature request for CHECKIN/OUT extension

Geoff,

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, August 06, 2001 8:07 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Feature request for CHECKIN/OUT extension
>
>
> Perhaps you could explain what benefit this "expected version URL"
> would provide.  In the W3C, you have a human meaningful URL, which
> DeltaV would call the version-controlled resource.  The resource

In W3C we have both:

1) the URI of the version controlled resource, for instance
<http://www.w3.org/TR/xslt> points to the "latest" version of the XSLT
recommendation.

2) we also have URIs for the equivalents of the checked-in versions, for
instance <http://www.w3.org/TR/1999/REC-xslt-19991116> will always refer to
the XSLT recommendation published on Nov 16, 1999. *Right now*, it refers to
the same document.

Note that the document referred by
<http://www.w3.org/TR/1999/REC-xslt-19991116> *contains* this URI as part of
it's content. Under deltaV this means that a client must be able to know the
URI of the version (when checked-in) before actually doing the CHECKIN to
accomplish the same.

> at this URL has a property that points at the latest immutable version,
> which DeltaV calls the DAV:checked-in version.  I am not aware of
> the W3C having a URL for "the next version that will be created".

I didn't say that (hopefully :-).

> Many versioning repositories do not allocate the version URL
> until the version is actually created, and therefore would not
> support the "expected version" feature.  In particular, for a repository

Sure. So does ours. But it generally will use an (internally) well-defined
mechanism to allocate the next URI, so a server possibly could pass the
information about the *expected* next checkin URI to the client unpon
checkout. If it can't provide it, it doesn't need to (and a client will have
to live with this). If it does provide it, but upon CHECKIN the server
decides it can't use that URI after all, the client will get an error
message (allowing him to recover).

> that supports branching and unreserved checkouts, the client
> that gets a particular version URL depends on which client
> checks in first.  I would be reluctant to add
> a feature like this which will cause interoperability problems,
> unless there is a compelling use case that requires it.

1) If the feature is implemented as outlined below, it shouldn't cause
interoperability problems. Servers can signal that they can't determine the
"expected checkin URI". If they do, they are also free not to accept this
URI upon CHECKIN (and to produce a new one). This would happen in the case
you mentioned.

2) I think I have given the use case. It basically requires that a
checked-in version can carry it's own URI (of the checked in version) in
it's content. This is a mandatory requirement for the versioning system we
have to expose through WebDAV, so we have to either define a proprietary way
to achieve this, or the protocol needs an extension. We think this use case
may apply to many others, and this is why we are trying to get a discussion
and possibly a consensus here...

Regards, Julian

> -----Original Message-----
> From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de]
> Sent: Monday, August 06, 2001 10:50 AM
> To: ietf-dav-versioning@w3.org
> Subject: Feature request for CHECKIN/OUT extension
>
>
> Feature request for CHECKIN/OUT extension
>
> In many cases, a versioning-aware client might want to display/include the
> URI of the version it's editing *while* it's edited. For instance, a
> versioning
> aware editor might include this as meta-information, or the author of a
> document might want to know the URI of the version *before* it's
> checked in.
> A well-known example is the W3C way of referring to document versions in
> recommendations: it contains HREFs to "the current version", to "this
> version"
> and to the "previous version". Something like this is currently impossible
> with deltaV, as the version URI is determined at the time of CHECKIN.
>
> Proposal:
>
> 1) Extend CHECKOUT to optionally return an "expected CHECKIN URI".
> 2) Extend CHECKIN to optionally use the "expected CHECKIN URI",
> failing the
> request if it's not possible to checkin the resource with the desired
> version URI (in which case a new "expected CHECKIN URI" is returned).
>
> Some possible strategies:
>
> 1) Pass the information as proprietary live properties.
> 2) Pass the information as properties in the DAV: namespace, and
> define the
> behaviour in the deltaV spec.
> 3) (preferred) Pass the information in the request/response bodies of
> CHECKIN / CHECKOUT, such as:
>
> CHECKOUT method:
>
> >>REQUEST
>
>   CHECKOUT /foo.html HTTP/1.1
>   Host: www.webdav.org
>   Content-Type: text/xml; charset="utf-8"
>   Content-Length: xxxx
>
>   <D:checkout xmlns:D="DAV:">
>     <D:compute-expected-version-URI />
>   </D:checkout>
>
>
> >>RESPONSE
>
>   HTTP/1.1 200 OK
>   Cache-Control: no-cache
>   Content-Type: text/xml; charset="utf-8"
>   Content-Length: xxxx
>
>   <D:checkout xmlns:D="DAV:">
>
> <D:expected-version-URI>http://repo.webdav.org/his/23/ver/32</D:ex
> pected-ver
> sion-URI>
>   </D:checkout>
>
>   (Note that we would need to define an (optional) response body for
> CHECKOUT).
>
>
> CHECKIN method:
>
>
> >>REQUEST
>
>   CHECKIN /foo.html HTTP/1.1
>   Host: www.webdav.org
>   Content-Type: text/xml; charset="utf-8"
>   Content-Length: xxxx
>
>   <D:checkin xmlns:D="DAV:">
>
> <D:expected-version-URI>http://repo.webdav.org/his/23/ver/32</D:ex
> pected-ver
> sion-URI>
>   </D:checkin>
>
> >>RESPONSE
>
>   HTTP/1.1 201 Created
>   Location: http://repo.webdav.org/his/23/ver/32
>   Cache-Control: no-cache
>
>   or
>
> >>RESPONSE
>
>   HTTP/1.1 409 Forbidden
>   Cache-Control: no-cache
>   Content-Type: text/xml; charset="utf-8"
>   Content-Length: xxxx
>
>   <D:error xmlns:D="DAV:">
>     <D:cannot-assign-expected-version-URI />
>
> <D:expected-version-URI>http://repo.webdav.org/his/23/ver/33</D:ex
> pected-ver
> sion-URI>
>   </D:error>
>
>
>
>
>

Received on Thursday, 9 August 2001 07:42:58 UTC