Re: First cut at Functional Requirements document

Fabio Vitali (vitali@cis.njit.edu)
Tue, 11 Jun 1996 14:54:10 -0500 

Hi!

Feeling like I'd like to make a fool of myself again, today, and to be
flamed about the real meaning of my life and reasons for freeing the world
of my presence, or even worse to be disdainfully ignored.

>	F.R. for Web Access to Version Control Systems

Personally, I don't like this title very much. It gives a certain slant to
it,  which I am uneasy with: that VCS are an external reality, an
indipendent variable, and that more or less the ones to be interested in
version control on the WWW are the VCS people. That is: "guys, this is not
a WWW issue, it's a bunch of people from a specific interest group who is
interested in using the Web for their own little tricks. As such, we should
give them the same attention and interest of those proposing F.R. for Web
access to Coke vending machines or F.R for Web access to astronomical
instruments".

Well, to me versioning on the Web IS definitely a Web issue, not a VCS
issue. It might be solved (it *should* be solved) by VCS people, it should
even help VCS people to provide a natural distributed extension to their
products, but it should be clear who's giving and who's receiving here. We
HAVE to make clear that this is something that the WWW as a WHOLE is
getting advantages out of.

I can't think of a "perfect" title right now, but this one definitely means
"would you mind that we do our little things here, if we do not disturb
grown-ups?".

Therefore,

FIRST we have to understand and agree WHY is versioning important for the
WWW. And, no, "being able to sell more copies of our XY product" is not a
reason.

SECOND come up with a title that somehow reflects this insight, and more or
less would force the WWW people to listen to our proposals

THIRD define what are the Functional Requirements to versioning FOR the
web, rather than the syntactical requirements for embedding version
information within URLs, HTTP headers, or HTML tags.

FOURTH deal with the requirements on syntax and stuff.

Therefore, here's a few ideas I have, more or less

   Functional requirements for version support for the World Wide Web

Rationale:

- Versioning of WWW resources is useful for several reasons (collaborative
authoring, document management, external link-bases, awareness of the past,
legal requirements, you name it).
- Versioning introduces a new level of specification for resources, since
we want to be able to specify not just a resource, but a specific state of
that resource as well (a specific version). Whether this state is in itself
an autonomous resource, or not, is not something that we are allowed to
decide.

Definitions
- What a resource is (what is a version of a cgi application?)
- What a version of a resource is (is it a resource itself? And if so, can
it be versioned?).
- What a configuration is (is it a complex entity? What are the relations
between configurations and other complex entities that are already defined
and used in the WWW?)

Requirements
- Each VCS will provide the user with a vast and relevantly different set
of operations on versions and configurations of resources
- Operations can be divided in three classes (thanks, Christopher):

>1)      GET -- browsing versioned entities.
>
>2)      PUT -- "checking in" a newly authored version of an entity.
>
>3)      VC -- doing all the ancilliary configuration management activities.

As far as the GET class is concerned, there are three types of operations
supported:
- Access to versions of resources (surf across the past)
- Access to version-defined ancillary resources of a version (surf into the
past)
- Access to a "default" version (as defined by VCS policies), when no
version information are given or needed.

Can we discuss what kind of operations we *should* support as far as PUT
and VC operations are concerned?