W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Mutable Versions (was: re-use of version URL's)

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Fri, 5 Jan 2001 16:49:40 -0500 (EST)
Message-Id: <200101052149.QAA00276@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
   From: "Lisa Dusseault" <lisa@xythos.com>

   I believe the requirements for code repositories and the requirements
   for document repositories are in some sense incompatible.  Thus, the
   client can't count on certain things being true for both kinds of

As of yet, I don't see these incompatibilities.  Document repository
users want to give things human meaningful names.  So do code
repository users.  Code repository users want to also give some things
stable names.  At least some document repository users want this as
well, as reflected by the fact that many document repository systems
today provide immutable stable names for document versions.  And for those
document systems that currently do not provide stable names, we have
described a simple technique for "stabilizing" the names (that I
believe you have agreed does not present implementation difficulties).

I don't see a problem/incompatibility here.

   We may need:
    - "type A" where the client can count on versions being immutable and
   version URLs being non-reusable
    - "type B" where the client can count on versions being mutable and
   version URLs being readable.

   I agree the client needs to be able to count on certain behaviour, but
   it will have to be a different kind of behaviour depending on what kind
   of server it is talking to.  Otherwise the needs of document-versioning
   servers will NOT be met by the versioning draft.

Just to ring that bell one more time, I agree that type B clients
need mutable (and human meaningful) URL's, but since they can use
version-controlled resource and non-version-controlled resource
URL's for this, I don't see why they need version URL's for this
as well.

Received on Friday, 5 January 2001 16:50:29 UTC

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