Re: More versioning thoughts.

David G. Durand (dgd@cs.bu.edu)
Thu, 6 Jun 1996 14:04:48 -0400 

Andre van der Hoek <andre@bigtime.cs.colorado.edu> wrote:

>After reading David's and other's thoughts on versioning in HTML, a couple of
>things come to mind for me:
>
>   * It looks like different users are trying to push different capabilities.
>     Although expected, I think we should agree on a common `goal' for
>     versioning in HTTP. Are we trying to simply put versioning capabilities
>     in HTTP, are we trying to put *a* versioning capability in HTTP, are
>     we trying to seamlessly integrate versioning and non-version aware
>     clients/servers,etc. It looks like the group needs an objective very much;
>     this in itself could be an interesting exercise, because I think we
>     will be able to identify multiple layers of functionality that can be
>     built on top of eachother.
Basic purpose:
   I think we need to put hooks into the WWW generally (at a minimum URLs
and HTTP are affected) so that versioning capabilities in general can be
added in accordance with end-user needs.

Pratical requirement:
I think compatibility with non-version aware software is a practical
necessity, unless the rest of ther world has some sort of version
conversion experience. I've been waiting long enough that I've given up
expecting that it will ever be 100% accepted.

>   * Thus, I like to make a distinction between versioning in HTTP, which is
>     a communication protocal, and versioning of web-pages, which is a much
>     higher level problem. It seems like the two are getting confused in some
>     of the earlier messages.

I think that we should take a lead from the name of this group "Working Group on
Versioning and Configuration Management of World Wide Web Content". This
means that we should have broader concerns than just HTTP, or just URLs.
For instance HTML specific stuff might be appropriate if it's distinct from
other data types in some way (though I suspect that at least all text/*
data types could be trated the same).

On the other hand, dealing with URLs first, and HTTP second seems sensible
as an order in which to freeze definitions. I do think that these levels
will interact, so that we may not always be able to restrict discussion
strictly to "just HTTP issues" in isolation from a notion of how the whole
thing will work together.

>Before I start rambling too much (which I probably already did), I think the
>group needs to have a common set of goals, possibly layered in some
>hierarchical plan of attack, as well as a clear separation between versioning
>features in HTTP, and higher level issues.

I'm not so sure the separations will be clean, so I'd rather focus
piece-by-piece on parts of the WWW technology base. I think we have a clear
order:

  + URL convention. We must be able to name things and versions of things.

  + HTTP issues. We must be able to send things around, along with needed
version information.

  + Content-type issues. We <em>may</em> want to say something specific
about some data types, or provide some specialized languages for doing
versioning-specific things. VTML tried to address passing a complete
document revision tree. We could also address passing updates as well.

   + Configuration management issues? I'm not expert on this stuff, but
there are surely some issues here. We need to think if this stuff makes any
hard requirements on the lower levels, or can just layer on top of anything
even halfway reasonable.

   -- David

----------------------------------------------+----------------------------
  David Durand                 dgd@cs.bu.edu  | david@dynamicDiagrams.com
  Boston University Computer Science          | Dynamic Diagrams
  http://cs-www.bu.edu:80/students/grads/dgd/ | http://dynamicDiagrams.com/