W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2002

RE: Can there be multiple BINDs to a VCR?

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Wed, 26 Jun 2002 23:56:48 +0200
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEHEENAA.julian.reschke@greenbytes.de>

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Wednesday, June 26, 2002 11:20 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Can there be multiple BINDs to a VCR?
>    From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
>    given a resource with the distinct URLs "/a1" and "/a2" (so both URLs
>    identify the same resource).
>    1) Is it allowed to VERSION-CONTROL this resource?
> Yes.
>    2) If yes and assuming that the VCR is checked out, what is the
>    DAV:checkout-set of the "current" version (the version
> identified by the
>    VCR's checked-out property)? Does it contain DAV:href elements for both
>    URLs?
> That's up to your server.  It must at least have the request-URL
> of the CHECKOUT request.  A client cannot count on having both URLs

If a server supports "real" bindings, it would be hard to guarantee this.

In particular, what about if "/a1" is checked out, then deleted. What would
be the DAV:checkout-set of the checked out version?

> in the DAV:checkout-set, because that is not required by the protocol.

That's right. I think the only thing that the protocol requires is that for
each checked out resource, one (of possibly many) resource URIs is reported.

> Note that in general, there will not be a list of all URLs, because
> there can be an infinite number of URLs that identify a resource when
> a collection that contains the resource also contains a binding to
> itself.

Right -- that would be the case discussed in [1]. This is a problem
everytime a method needs to generate "a" URI for a given resource (same for
many REPORTs...).

Received on Wednesday, 26 June 2002 17:57:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC