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

Re: Overview of Core versioning

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 25 Feb 2001 01:41:32 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B10221D24C@SUS-MA1IT01>
To: "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
   From: Lisa Dusseault (lisa@xythos.com)

   I've noticed that there is a "rationale" for versioning options,
   but not for core versioning.  I think something is needed more than
   the no-op definition of "the set of stuff defined in section 3".
   Core is specific enough that we should be able to describe, in a
   few brief paragraphs, precisely what it accomplishes.  Thus, I've
   suggested some text which can serve as an introduction to, overview
   of, and explanation of Core Versioning.  It's important to frame
   and position technical requirements, because readers understand
   technical specifications much better if they understand what its
   for, and what it does, first.

Lisa: Sorry I didn't get to this in time for version 14, but I'll get
these changes made during the IESG last call period.

   "Core versioning" is the set of properties and method semantics
   defined by Section 3 of this document.  Core versioning serves to
   establish a common model to organize and understand constructs
   which exist on any versioning server.  Core versioning makes a
   number of requirements on how servers must handle
   version-controlled resources, so that clients have a reasonable
   model for what effect a command will have.

   Core versioning makes requirements on servers but not on
   clients. The intent of this choice is that clients be able to rely
   on a minimum level of functionality when they contact a
   DeltaV-capable server. Since all HTTP actions are initiated by the
   client, the server has no need to know a priori what functionality
   the client supports. TO the extent to which the server needs to
   know, the client can tell it in its requests.

In Yaron Golan's review, he vehemently objected to statements that are
generically true for all HTTP protocol extensions.  I believe that the
previous paragraph suffers from this problem, i.e. these statements
are true, but have nothing in particular to do with versioning.

What do other folks think?

   A server which implements Core Versioning can interoperate successfully
   with a client which is completely ignorant of DeltaV. Unless the client
   requests versioning functionality, a Core-compliant server will
   automatically behave like an non-versioning WebDAV server. Thus, a
   versioned resource automatically behaves in an unsurprising way when
   operated upon by WebDAV or HTTP methods.

Yes, this definitely needs to be said!  I'll make this point in the
"Relationship to WebDAV" section.

   A client can use OPTIONS to find out if a server supports core
   versioning.  If the server does support core versioning, the client can
   then be assured that it can:

    - Browse version-controlled resources and differentiate them from
   non-versioned resources,


    - Use VERSION-CONTROL method to put resources under version control,


    - Browse past versions of version-controlled resources,


    - View some basic information about these resources,

that seems a bit vague to me.

    - Find out whether and how new versions will be created automatically
   by the server (auto-version)


    - Predict what effect HTTP/WebDAV operations will have on a given
   resource with a given version history

that also seems a bit vague to me.

If nobody objects, I'll add this enumeration of core versioning
features to the Introduction.

Received on Sunday, 25 February 2001 01:42:12 UTC

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