W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1996

Referring to versions

From: David G. Durand <dgd@cs.bu.edu>
Date: Fri, 1 Nov 1996 13:34:25 -0500
Message-Id: <v02130502ae9fe9a32335@[128.148.157.46]>
To: Distributed Authoring List <w3c-dist-auth@w3.org>

   The real reason that referring to versions is hard is that there are
some many different things that it is reasonable to do. They also interact
with  configuration management -- the problem of making sure that sets of
linked resources are consistent and what the author wanted.

   In the software engineering community, the notion of composite iobjects
has led to a number of distinct policies for deciding when making a new
version of a part creates a new version of the whole. Hypertext complicates
this again by adding links between resources.

   One may plausibly want at least the following sorts of links:
   Always current: This kind of link specifies a resource; the version of
the resource must always be a unique "most up-to-date version" (according
to some global config. mgt. policy). There can only be one most up-to-date
version. Think of publications, where an update to one resource should
invisibly propagate to all references to the resource.

   Always fixed: This kind of link (think editorial annotation) must always
point to a specific version of a resource. It is not necessarily sensible
to "forward" editorial comments to new versions of a resource/

   Version consistent: This kind of link should point to the proper version
of a related resource, depending on the version of the resource containing
the link. (note that a link like this depends on some kind of configuration
management context that associates versions of different resources with
each other).

Now these are all useful and they point to a fundamental fact (logically
speaking). Resources are essentially indexed by their versions, which are
organized as a lattice with a top element under the derived-from relation.
configuration managers define maps between version trees. There are a
veriety of version queries that a link could resonably make, these should
be supported by URLs.

   Now I don't care if we hack URLs, myself, although I think that versions
are integral enough to identity questions that they deserve a place in a
URL or URN framework. But we need to have _some URLs_ that refer to all
these types of version query (at least the three specific ones I've
mentions). We can construct these URLs by URL-hacking, or we can query the
server for the information, but there needs to be a way for an author do
determine and use the right URI to make the links-types given above.

    An older, but relatively clear and easy to read hypertext paper (By
Hicks, Leggett, and Schnase [TAMU HRL-91-004]), explains the basic issues
of linking in the presence of versions. It's available (as Postscript,
sigh) from Texas A&M's Hypermedia Research lab (Somewhere off
www.bush.cs.tamu.edu). Other views can be found in several papers by Anja
Haake, David Hicks, Kaspar Østerbye, Ufe Wiil, John Leggett, and others in
the last 4 or 5 ACM Hypertext conference proceedings. I'm not advocating
that we fix a single set of configuration management semantics -- there is
not a consensus on a single right solution, or event he existence of such a
solution -- but we should construct a framework within which such things
cvan be constructed.

   Fortunately, I think we can define sufficient versioning to get the
first two kinds of links I mentioned without having to commit on the large
nest of snakes  (oops I mean questions), involved in configuration
management.

  -- David

RE delenda est.
I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
Received on Friday, 1 November 1996 13:29:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:41 GMT